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ABSTRACT 


This  thesis  introduces  the  Modular  Command  and  Control 
Evaluation  Structure  (MCES)  as  a  tool  which  the  author 
recommends  for  command  and  control  ( C 2 )  planners  to  use  when 
addressing  interoperability  management  problems.  The  framework 
of  MCES  is  used  to  identify  the  inadequacies  of  the  Marine 
Corps  Technical  Interface  Concepts  (TIC)  as  an  interoperability 
management  tool  and  provides  some  insight  into  how  to  better 
define  interoperability  requirements  in  terms  of  message 
exchange  occurrences  (MEOs).  MEOs  are  the  building  block  of 
interoperability,  and  they  can  be  stored  along  with  their 
elements  of  decomposition  in  an  integrated  interoperability 
database  (IIDB)  for  use  by  C2  planners. 
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I.  INTRODUCTION 


A.  STATEMENT  OF  THE  PROBLEM 

In  the  past  decade  interoperability  problems  have  become 
intense  as  technological  advancements  in  the  electronic 
industry  drive  communications  equipment.  Designers  of  command 
and  control  (C2)  system  architectures  may  have  been  overly 
influenced  by  equipment  specifications.  In  designing  a 
communication  system  to  support  a  C2  architecture  they  have 
concentrated  primarily  on  capabilities  derived  from 
technological  advancements,  rather  than  on  information  flow 
and  mission  requirements.  In  some  instances,  communications 
system  equipment  interoperated  effectively,  while  the  C2 
architecture  to  be  supported  was  unable  to  operate  effectively 
as  a  system.  [Ref.  1] 

When  individuals  or  command  centers  within  a  C2 
architecture  are  not  able  to  interoperate,  they  lack  the 
ability  to  effectively  function  as  a  system  working  towards  a 
common  goal.  The  lack  of  interoperability  in  a  C2  architecture 
could  manifest  itself  in  several  forms:  (1)  individuals  not 
understanding  or  misinterpreting  a  message,  (2)  command 
centers  not  able  to  exchange  valuable  military  information 
about  themselves,  or  (3)  individuals  and  command  centers  not 
fully  understanding  operational  procedures. 


A  major  goal  of  the  DOD  is  to  provide  military  planners 
with  accurate,  detailed  information  about  C2  system 
requirements,  about  the  interrelationship  of  tactical  C2 
systems,  and  about  the  impact  that  a  particular  C2  architec¬ 
ture  will  have  on  the  system  as  a  whole.  [Ref.  2:  p.  1] 

Interoperability  of  command  and  control  systems  can  be 
defined  in  terms  of  "information  flow".  However,  presently 
there  is  no  universal  accepted  methodology  within  the 
Department  of  Defense  (DOD)  for  documenting  "information  flow" 
in  a  command  and  control  architecture.  [Ref.  2] 

In  order  to  address  the  interoperability  problem  of  command 
and  control  architectures,  a  method  for  identifying,  capturing, 
organizing,  and  accessing  information  necessary  to  describe 
current  and  projected  command  and  control  systems  must  be 
adopted.  [Ref.  3:  p.  4]  The  methodology  must  be  able  to 
provide  a  detailed  view  of  a  command  and  control  structure,  and 
be  applied  as  a  dynamic  analysis  tool  for  problem-solving. 

[Ref.  2:  p.  1]  and  [Ref.  3:  p.  1] 

B.  OBJECTIVE  OF  THESIS 

This  thesis  addresses  some  of  the  challenges  issued  by 
Major  Steven  L.  Pipho,  USMC,  in  his  article  "Cutting  the  Gordian 
Knot  of  Interoperability:  A  Systems-Engineered  Solution  to  the 
Problem  of  Interoperability  Modeling."  [Ref.  2]  Pipho  asserts 
that : 

The  military  faces  a  formidable  challenge  today  in  the  area 
of  command,  control,  and  communications.  Powerful, 
[communications]  systems  which  exploit  a  rapidly  expanding 
technological  base  are  fast  becoming  realities;  yet,  issues 
concerning  their  integration  into  the  larger  context  of  a 
command  and  control  architecture  remain  unresolved. 


Military  planners  require  clearly  defined  standards  of 
compatibility  and  interoperability  to  retrofit  fielded  sys¬ 
tems,  modify  those  currently  in  design,  and  plan  for  futures 
ones.  [Ref.  2 :  p.  1 ] 

The  major  effort  of  this  thesis  deals  with  expanding  and 
applying  a  tool  to  enable  analysts  to  effectively  gain  new 
insight  into  the  problem  dealing  with  interoperability  of 
commmand  and  control  architectures.  Based  upon  Marine  Corps' 
efforts,  an  architecture  is  defined  as:  "An  aggregate  or  set 
of  elements  systematically  associated  and  structured  to 
accomplish  a  purpose  that  is  characterized  by  the  peculiar 
organization  of  its  elements."  [Ref.  2:  p.  ii]  Therefore,  a 
command  and  control  architecture  [system]  associates  elements 
of  command  and  control  whose  specific  structure  facilitates  the 
exchange  of  information  by  communications  to  support  the 
achievement  of  mission  objectives.  (See  Phipho,  1986) 

[Ref.  2:  p.  2] 

There  are  two  foci  in  this  thesis,  (1)  operational 
considerations  and  (2)  methodological  issue. 

1 .  Operational  Considerations 

After  their  attempt  to  design  an  air  defense  C2 
architecture  using  the  Technical  Interface  Concepts  (TIC) 


Concepts  for  Marine  Tactical  Systems,  both  the  author  and  Pipho 
agreed  that  the  methodology  set  forth  in  the  TIC  should  be 
examined  and  analyzed  for  its  ability  to  adequately  address 
interoperability  problems  on  an  architectural  level.  This  was 
undertaken  by  employing,  as  a  test  case,  the  Operational 


Facility  (OPFAC)  tasks  associated  with  a  C2  communications 
architecture  that  is  required  to  produce  an  air  tasking  order 
(Frag)  . 


2 .  Methodological  Issue 

Conversely,  by  examining  the  procedures  associated  with 
the  air  tasking  order,  this  thesis  will  verify  the  ability  of  a 
Lawson-like  C2  Process  model  to  practically  describe  service 
doctrine . 
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To  illustrate  the  above  point,  consider  a  Marine  air 
defense  system  which  is  composed  of  the  following  control 
facilities/agencies: 

-  Tactical  Air  Control  Center  (TACC) 

-  Tactical  Air  Direction  Center  (TADC) 

-  Tactical  Air  Operation  Center  (TAOC) 

-  Light  Antiaircraft  Missile  Battery (LAAM) 

-  Forward  Area  Air  Defense  Battery  (FAAD) 

Each  of  these  facilities/agencies  are  made  up  of  several 
subordinate  units  and/or  sections  which  perform  unique  tasks, 
such  as  the  LAAM  battery  which  has  an  Antiaircraft  Operations 
Center  (AAOC)  and  a  Battery  Control  Center  (BCC).  If  the 
subordinate  units  and/or  sections  within  a  facility/agency  are 
unable  to  interoperate  among  themselves,  then  that  facility/ 
agency  lacks  interoperability.  And  if  a  facility /agency 
does  not  have  interoperability  within  itself,  then  it  can  not 
operate  effectively  as  a  subordinate  part  of  a  larger  organiza¬ 
tion.  In  order  for  an  air  defense  system  to  be  interoperable, 
interoperability  must  be  established  throughout  the  entire 
system.  The  hub  of  the  Marine  Corps'  air  defense  operation  is 
the  TAOC.  (See  Figure  2.1)  The  TAOC  must  be  able  to  interoper¬ 
ate  with  the  TACC/TADC,  LAAM  battery,  and  FAAD  battery.  If  any 
of  these  organizations  could  not  interoperate  with  the  TAOC, 
then  there  would  not  be  an  air  defense  system.  The  air  defense 
system  requires  that  all  of  its  facilities/agencies  be  inter¬ 
operable  in  order  to  be  considered  a  system. 

The  official  Department  of  Defense  (DOD)  definition  for 
command  and  control  is: 


LAAM 

BATTERY 


TAOC 


FAAD 

BATTERY 


Figure  2.1.  A  Simple  Air  Defense  System. 
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The  exercise  of  authority  and  direction  by  a  properly 
designated  commander  over  assigned  forces  in  the  accomplish¬ 
ment  of  the  mission.  Command  and  control  functions  are 
performed  through  an  arrangement  of  personnel,  equipment, 
communications,  facilities,  and  procedures  which  are  employed 
by  a  commander  in  planning,  directing,  coordinating,  and 
controlling  forces  and  operations  in  the  accomplishment  of 
his  mission.  [Ref.  3:  p.  2-2]  and  [Ref.  5:  p.  23] 

Therefore,  C2  is  the  total  and  all  encompassing  process  of 
a  commander  accomplishing  a  mission  through  the  assets  of  his 
assigned  forces.  The  commander  controls  and  directs  his  forces 
by  some  means  of  communication,  which  can  range  from  a  simple 
manual  technique  (speech)  to  a  fully  automated  facility,  such 
as  a  naval  communication  station  (NAVCOMMSTA).  Thus,  all  forms 
of  communication  and  their  supporting  facilities  are  only  means 
which  a  commander  and  his  forces  utilize  to  pass  information  to 
one  another,  in  order  to  interoperate  and  effectively 
accomplish  the  assigned  mission.  In  support  of  C2,  C2  systems 
are  developed,  acquired,  and  fielded.  The  JCS  Pub  2  definition 
of  command  and  control,  and  information  system  is  used  to 
define  C2  systems: 

An  integrated  system  comprised  of  doctrine,  procedures, 
organizational  structure,  personnel,  equipment,  facilities, 
and  communications  which  provides  authorities  at  all  levels 
with  timely  and  adequate  data  to  plan,  direct  and  control 
their  operations.  [Ref.  3:  p.  2-3] 

2 .  Interoperability  of  a  C2  Architecture 

Based  on  the  above  definitions  of  interoperability,  C2, 
and  architecture;  "interoperability  of  a  C2  architecture"  will 
be  defined  for  this  thesis  as:  The  ability  of  an  aggregate  set 


of  control  faciltities/agencies  associated  with  an  architecture 


to  exchange  services  among  themselves,  so  that  the  exchanges 
enable  a  commander  to  accomplish  his  mission.  This  definition 
emphasizes  the  C2  architecture  and  not  the  specific  communica¬ 
tion  system  which  supports  it. 

Although  interoperability  of  communications  systems  is 
important,  the  information  requirements  and  functional 
relationships  of  a  C2  architecture  must  first  be  defined. 

Then,  the  communication  system  to  support  a  peculiar  C2 
architecture  and  its  interoperability  requirements  can  be 
identified.  Following  this  sequence  will  better  enable 
planners  of  communications  systems  to  design  systems  which  will 
support  a  commander  in  accomplishing  his  mission,  rather  than 
one  which  usually  limits  him.  [Ref.  2] 

B.  HISTORICAL  PRECEDENCE  FOR  THE  WORK 

In  the  early  70’s,  the  Marine  Corps  realized  it  had  a 
problem  with  interoperability  of  C2  systems  and  attempted  to 
resolve  this  problem  through  the  Landing  Force  Integrated 
Communications  System  (LFICS)  program.  During  1985  the  LFICS 
program  was  redirected.  The  new  thrust  was  to  develop  a  concep¬ 
tual  framework  that  could  combine  information  requirements  and 
information  flow  with  the  constraints  imposed  by  a  particular 
configuration  of  communications  and  information-processing 
equipment.  [Ref.  1:  p.  2] 

In  the  conceptional  framework  of  LFICS,  C2  doctrine  and 
operational  requirements  generated  information  needs.  These 


information  requirements  were  originally  known  as  Needlines, 
later  as  Message  Exchange  Occurrences  (MEOs).  A  MEO  summarizes 
a  requirement  for  information  exchange  between  two  nodes.  A 
MEO  consists  of  a  sender,  receiver,  message  to  be  transmitted, 
and  the  circuit  medium  in  which  to  pass  the  message.  (See 
Figure  2.2).  Above  the  line  is  the  message,  below  the 
circuit.  The  flowline  shows  sequence  and  simple  timing  on  the 
network.  MEOs  could  be  chained  to  one  another  to  form  a  net¬ 
work  that  represented  information  flow  over  time.  (See  Figure 
2.3)  [Ref.  1,  11]  and  [Ref.  6] 

At  the  heart  of  the  LFICS  architecture  was  a  large 
information  base  which  consisted  of  a  number  of  related 
databases.  It  was  planned  that  the  LFICS  information 
base  would  contain  information  on  the  composition  of  MEOs 
(source  nodes,  sink  nodes,  message  types,  and  circuit  medium) 
and  communications  equipment  specifications.  After  the 
construction  and  maintenance  of  this  information  base,  it  was 
contemplated  that  system  planners  and  managers  would  have  a 
baseline  from  which  to  manage  their  systems.  [Ref.  1:  p.  2] 

The  author’s  interpretation  of  the  LFICS  information  base 
is  depicted  in  Figure  2.4.  This  interpretation  structures  the 
information  base  as  a  hierarchy  of  databases.  Each  database 
points  to  other  databases  which  were  either  a  subset  or 
decomposition  of  a  higher  order  database.  For  example,  the  MEO 
database  would  point  to  the  C2  nodes  database,  message  types 
database,  and  the  circuit  standards  database. 


"Given  C2  doctrine  and  operational  requirement, 
a  need  for  information  is  generated" 
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Figure  2.2.  A  MEO  for  an  Air  Defense  Envelope 
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Figure  2.3.  Flowiine  for  an  Air  Defense  Example 


Figure  2.4.  An  Interpretation  of  the  LFICS  Information  Base 


An  information  base  would  be  useful  to  many  different  types 


of  users.  Below  are  six  broad  user  areas  suggested  by  Pipho 
[Ref.  1]  in  his  point  paper  titled  ”  A  Development  Strategy  for 
a  LFICS/C4I  Architecture": 

1 .  System  Developers 

System  developers  have  an  obvious  need  for  a  [LFICS] 
information  base  .  .  .  .  the  nature  of  the  job  requires 
them  to  extend  their  knowledge  of  the  current  communica¬ 
tions  systems  to  assess  future  requirements. 

As  sophisticated  systems  are  proposed  and  accepted,  the 
R&D  community  must  ensure  that  diverse  systems  can  be 
integrated  efficiently  into  the  general  architecture.  A 
typical  application  program  would  likely  extract  information 
from  one  database  containing  equipment  specifications, 
system  components,  and  interoperability  standards  such  as 
interfaces,  protocols,  etc.,  and  information  from  another 
dabase  on  how  the  various  sytems  are  to  be  used,  where  they 
would  be  deployed,  and  the  number  and  kind  of  skills  required 
to  operate  and  maintain  a  system.  Additionally,  an  R&D 
database  could  contain  information  on  engineering  change 
proposals  for  systems  under  development  to  enable  a  project 
officer  to  ascertain  the  effect  of  a  proposed  modification. 

2 .  The  Fleet  Marine  Forces 

A  good  applications  program  for  the  [Fleet  Marine  Force] 

FMF  would  assist  the  [communication  electronic  officer]  CEO 
or  communications  officer  in  the  detailed  planning  of  his 
communications  "order  of  battle."  He  may  want  to  access  a 
database  to  gain  detailed  specifications  of  the  equipment 
that  is  organic  to  his  unit.  Or,  perhaps,  he  would  want  to 
analyze  the  loading  of  his  particular  node  by  examining  the 
quantity  of  data  and  data  rate  he  needs  to  successfully 
pass  information  between  a  sender  and  receiver  for  a 
particular  type  of  exchange. 

3 .  Acquisition  Managers 

HQMC  recently  requested  MCTSSA  and  MCDEC  to  comment  on  a 
proposal  to  use  the  LFICS  study  developed  by  TRIAD  Corpora¬ 
tion  to  ascertain  the  [communication  security]  COMSEC 
requirements  for  the  1990's.  The  idea  was  to  examine  the 
information  needlines  [MEOs]  and  flowlines  in  the  loading 
analysis,  count  the  number  of  secured  nets,  note  their  type 
and  produce  a  final  count  of  COMSEC  equipment  by  category. 


4 .  Doctrine  Developers 


Doctrine  plays  a  key  role  in  the  [LFICS]  architecture.  It 
fundamentally  influences  the  needlines  [MEOs]  and  flowlines 
of  the  communications  systems  because  it  defines  the  elements 
of  a  combat  team  and  the  relationships  between  them.  An 
applications  program  for  members  of  the  Doctrine  Branch  or  the 
Advanced  Amphibious  Warfare  Study  Group  would  be  one  which 
would  access  a  database,  extract  organization  and  C2  informa¬ 
tion,  and  explore  the  effects  of  doctrine  changes  on  the 
communications  system  by  substituting  or  changing  the 
composition  of  a  combat  force. 

5 .  Educators 

The  [LFICS]  information  base  can  be  viewed  as  the 
repository  for  all  [ C 2 ]  information.  Students  at  the 
intermediate  and  senior  level  [military]  schools  could  have 
programs  that  give  them  basic  information  about  Marine  Corps 
[C2]  architecture.  Additionally,  schools  could  request 
applications  programs  to  enable  students  to  validate  their 
solutions  to  school  exercises  in  the  area  of  [ C 2 ] 
supportability . 

6 .  Others 

.  .  .  .  the  [LFICS]  information  base  could  serve  a  wide 

variety  of  uses.  Its  utility  could  be  extended  by  incor¬ 
porating  ports  to  other  information  bases  (e.g.  ,  JINTACCS) 
to  access  information  on  a  wide  variety  of  matters.  Its 
usefulness  is  really  limited  only  by  our  imagination  and 
ingenuity. 

The  general  concept  of  the  LFICS  program  of  designing 
communications  systems  based  on  mission  requirements  was  an 
excellent  idea.  According  to  Pipho  [Ref.  1]  the  key  to  the 
LFICS  program  success  will  be: 

.  .  .  an  extensive  analysis  of  the  [C2]  information  require¬ 

ments.  Once  these  requirements  have  been  identified  and 
verified,  they  can  be  matched  with  various  sets  of  equipment 
to  determine  the  effectiveness  and  efficiency  of  a  particular 
[  C  2 ]  architecture. 

However,  several  attempts  were  made  to  implement  a 
LFICS  architecture,  but  they  were  unsuccessful.  Phipho  states 
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that  the  "failure  of  earlier  attempts  was  that  each  [attempt 
drove]  the  model  [LFICS  architecture]  by  equipment 
specifications  rather  than  information  requirements."  Also, 
system  planners  for  LFICS  began  to  focus  on  communication 
needs,  rather  than  on  the  basic  issues  of  C2.  [Ref.  1] 

So,  after  nearly  20  years,  the  Marine  Corps  still  does 
not  have  a  satisfactory  information  base  with  which  it  can 
effectively  plan  the  acquisition  of  new  communication  systems 
which  support  a  C2  architecture.  [Ref.  1:  p.  1] 

C.  RELATED  WORK 

The  foundation  of  this  thesis  is  the  related  work  of  two 
major  efforts.  One  effort  is  the  Marine  Corps'  approach  to 
resolving  the  problem  of  interoperability.  A  significant  part 
of  this  effort  was  from  the  results  of  Major  Pipho's  work 
[Ref.  2].  The  other  work  evolved  from  a  series  of  workshops 
sponsored  by  MITRE  Corporation,  the  Military  Operations 
Research  Society  (MORS),  and  most  recently  the  Naval 
Postgraduate  School  (NPS)  series  of  workshops  held  during  the 
period  February  1984  to  January  1987  concerning  C3  measurement. 

1 .  Marine  Corps'  Approach 

Major  Pipho  has  proposed  a  tool  to  resolve  the  problem 
of  interoperability  management.  His  approach  to  this  dilemma 
is  to  first  simplify  the  concept  of  command  and  control  in 
order  to  have  a  better  understanding  of  the  basic  issues  of 
interoperability.  Secondly,  he  provides  a  baseline  concept 


for  the  design  and  implementation  of  a  command  and  control 
integrated  information  base  that  will  contain  the  necessary 
information  required  to  effectively  manage  interoperability. 
[Ref.  2]  A  discussion  of  the  fundamental  structure  of  C2 
architectures  is  provided  for  a  basic  understanding  of  Pipho's 
work . 

a.  Introduction 

A  command  and  control  architecture  is  composed 
of  one  or  more  message  exchange  occurrences  (MEOs)  operating 
together  to  support  the  commander  in  the  accomplishment  of 
his  mission.  Pipho  defines  a  MEO  to  be:  "A  unique  association 
of  four  essential  components  that  define  information  transfer 
at  the  fundamental  level.  These  components  are  source  command 
and  control  element  (C2E),  sink,  message  standard,  and  C2E  link 
standard."  (See  Figure  2.5)  A  C2E  consists  of  equipment, 
communication,  facilities,  personnel,  and  procedures  which 
perform  the  tasks  and  functions  of  a  C2  node.  A  message 
standard  is  "a  discrete  set  of  message  elements  that  carry 
information  between  C2Es."  A  link  standard  is  "a  discrete  set 
of  technical  specif icatons  requirements  that  characterize  the 
signal  interface  between  two  C2Es."  A  C2  node  may  consist  of 
one  or  more  C2Es.  [Ref.  2] 

b.  Fundamental  Structure  of  C2  Architectures 

The  simplest  of  C2  architectures  consist  of  two  C2 
nodes  where  each  node  is  represented  by  a  C2E.  If  the  C2Es 
have  an  exchange  of  information  over  a  link,  with  one  C2E 


always  transmitting  and  the  other  only  receiving,  then  the  C2 
architecture  can  be  defined  by  one  MEO.  (See  Figure  2.5)  The 
ability  of  two  C2Es  to  exchange  information  with  one  another  in 
the  support  of  some  mission  defines  their  interoperability. 

This  is  true,  because  in  order  for  two  C2Es  to  be  able  to 
exchange  information  they  both  must  be  able  to  handle  the  same 
discrete  set  of  message  elements  that  carry  information  between 
them  and  the  same  set  of  technical  specifications  requirements 
which  enables  this  exchange  of  information.  Therefore,  the 
MEO,  the  simplest  of  C2  architectures,  is  the  basic  unit  of 
interoperability.  [Ref.  2] 

Pipho  suggests  that  a  MEO  identifies  the 
interoper bility  requirements  of  larger  and/or  more  complex 
architectures.  Architectures  which  are  more  complex  can  be 
designed  by  interconnecting  MEOs  having  a  common  C2E  which 
supports  the  same  mission.  (See  Figure  2.5).  Pipho  makes  the 
following  comment  concerning  interoperability  of  a  C2 
architecture : 

An  [architecture]  that  consists  of  a  chain  of  validated  MEOs 
necessarily  reflects  the  compatibility  and  interoperability 
inherent  in  the  MEOs  that  created  it.  This  frees  the  user 
from  concern  about  the  validity  of  .  .  .  interoperability  in 
his  C2  [architecture].  Instead,  he  [the  user]  may  concentrate 
fully  on  the  flow  of  command  and  control.  [Ref.  2:  p.  5] 

The  validation  of  a  MEO  can  be  accomplished  by  verifying  that 

it  exists  at  some  point  in  time  according  to  doctrine  and/or 

from  the  experience  of  experts  in  the  field.  Once  MEOs  have 

been  validated  for  a  given  mission  area,  they  could  be  recorded 
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into  an  integrated  information  data  base  for  future  reference. 
C2  planners  and  designers  could  use  such  a  data  base  to  study 
the  implementation  of  potential  C2  architectures.  [Ref.  2] 

This  integrated  data  base  would  necessarily  contain  the 
interoperability  standards  for  any  C2  architecture  designed 
from  the  validated  MEOs  that  are  recorded  in  the  data  base. 

This  data  base  would  be  similar  to  the  one  proposed  for  the 
LFICS  program.  (See  Figure  2.4) 

Information  exchange  requirements  are  reflected  in 
MEOs.  However,  there  may  be  times  when  information  that  is 
required  to  support  a  task  can  not  be  passed.  Perhaps  the 
C2Es,  link  standard,  and/or  message  type  are  not  available  in 
the  appropriate  arrangement  to  facilitate  an  exchange  of  infor¬ 
mation.  Pipho  suggests  that  an  integrated  information  base 
could  assist  C2  planners  in  solving  this  problem.  [Ref.  2] 

The  first  step  toward  developing  the  integrated 
information  base  is  to  identify  the  set  of  basic  components 
that  define  the  C2  architecture.  At  the  most  general  level, 
these  are: 

-  C2Es 

-  C2E  tasks 

-  C2E  resources 

-  Information  required  to  perform  C2E  tasks 

-  Communication  capabilities  to  support  the  exchange  of 
information 


The  relationship  of  these  C2  components  is 
important.  Figure  2.6  displays  the  basic  C2  components  and 
their  relationship.  Resources  of  a  C2E  perform  tasks.  Tasks 
can  be  decomposed  into  subtasks  that  describe  what  activities 
the  C2E  is  required  to  perform.  In  order  to  accomplish  the 
defined  tasks  or  subtasks,  information  is  required  to  provide 
knowledge  about  the  tasks.  Information  is  of  little  value  if 
it  is  not  shared  quickly  by  those  who  need  to  act  upon  it.  So, 
information  is  exchanged  by  some  form  of  communications. 

[Ref.  2:  p.  8] 

Resources  can  be  grouped  into  two  general 
categories,  people  and  equipment.  Pipho  inferred  that  the 
degree  of  automation  employed  by  a  C2E  is  represented  in  the 
utilization  of  one  type  of  resource  over  the  other.  The  more 
equipment  used  to  accomplish  a  task  the  greater  the  automation. 
Figure  2.7  illustrates  the  point  that  a  C2E  can  have  two  types 
of  resources.  Personnel  perform  personnel  tasks.  The  person¬ 
nel  to  perform  these  tasks  require  some  knowledge  about  the 
task.  This  knowledge  is  contained  in  information  elements. 
Information  elements  are  then  grouped  into  a  message  for  an 
exchange  of  information.  Equipment  resources  follow  a  similar 
process.  Equipment  tasks  are  performed  by  equipment  and/or 
systems  of  equipment.  Signals  (mechanical  or  electrical)  pro¬ 
vide  equipment/systems  of  equipment  some  form  of  information  so 
that  they  can  perform  equipment  tasks.  However,  the  signals 
must  communicate  over  a  circuit.  The  ability  of  a  C2F  to 


exchange  information  with  another  C2E  displays  its  ability  to 
interoperate.  [Ref.  2:  pp.  5-7] 


Another  approach  to  viewing  the  components  of  a  C2E 
is  depicted  in  Figure  2.8.  The  C2E  components  (resources, 
tasks,  information,  and  communications)  have  some  degree  of 
interdependence.  An  increase  in  either  the  number  of  tasks, 
level  of  information,  or  amount  of  communications  will  demand 
larger  quantities  of  resources  to  perform  a  particular  func¬ 
tion.  This  increase  in  resources  is  captured  in  the  resource 
curve.  This  curve  is  for  illustrations  purposes  only.  The 
actual  slope  of  the  resource  curve  will  depend  on  the  scenario. 
Intuitively,  it  is  believed  that  the  resource  curve  will  always 
be  monotonically  increasing. 

The  characteristics  of  the  C2E  components  deter¬ 
mine  how  a  MEO  will  be  defined;  recalling  that  a  MEO  is 
defined  by  a  source  C2E,  sink  C2E,  message  standard,  and  link 
standard.  The  MEO  is  the  basic  unit  of  interoperability  and  is 
the  foundation  on  which  a  C2  architecture  should  be  designed. 
How  MEOs  are  derived  to  design  an  implementation  of  a  potential 
C2  architecture  is  the  underlying  focus  of  this  thesis.  The 
methods  proposed  in  the  workshop  series  will  be  employed  to 
provide  some  insights  into  the  interoperability  problem. 

2 .  Workshop  Effort 
a.  Introduction 

The  series  of  workshops  focused  on  an  evaluation 
structure  based  upon  measures  of  effectiveness  (MOEs),  which 
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Information 


would  assist  analysts  and  decision  makers  in  their  efforts  to 
evaluate  command  and  control  systems  in  terms  of  improved 
combat  effectiveness.  [Ref.  3:  p.  iii] 

The  workshop  series  resulted  in  an  evaluation- 
formulation  tool,  which  later  became  known  as  the  Modular 
Command  and  Control  Evaluation  Structure  (MCES).  MCES  is 


composed  of  seven  separate  modules  that  guide  the  analyst 
through  a  C3  evaluation,  as  illustrated  in  Figure  2.9.  [Ref. 
8]  Below  is  a  brief  description  of  the  MCES  methodology, 
b.  MCES'  Methodology 


Module  One  (Problem  Formulation 


Module  one,  the  problem  formulation  block,  addresses  the 
question  of  the  decision  maker' s  needs  and  objectives  in  a 
specific  problem.  For  a  military  sytstem,  these  could 
include  the  concept  definition  and  development,  system 
design,  acquisition,  or  operations.  This  module  is 
analogous  to  the  systems  approach  "objectives  of  the 
system.  .  .  .  those  goals  or  ends  toward  which  the  system 
tends."  The  objectives  need  to  be  identified  as  "real" 
goals  or  "stated"  goals,  and  once  identified,  need  to  be 
operationalized.  [Ref.  7] 


( 2 )  Module  Two  (C2  System  Boundint 


Module  two  is  the  system  bounding  block  and  is  used  for 
identifying  relevant  quantities,  including  physical  entities 
and  structure,  and  boundaries  of  the  subsystem,  system,  own 
forces,  environment  and  reset  of  the  world.  Figure  2.10 
depicts  the  "onion  skin"  that  describes  the  MCES  systems 

bounding . [Module  two]  includes  everything  outside  the 

system's  control  [the  environment]  and  everything  that  deter¬ 
mines  how  the  system  performs.  [Ref.  7] 


(3)  Module  Three  (C2  Process  Definition 


Module  three,  the  process  definition  module,  takes  a  given 
system  configuration  (i.e.,  a  specific  scenario  and  mission) 
and  defines  the  processes  needed  to  fulfill  the  mission.  It 
maps  the  processes  needed  to  fulfill  the  mission.  It  maps 
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Figure  2.9.  Modular  Command  and  Control  Evaluation  Strucure  (MCES) . 
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the  processes  needed  to  a  Lawson-like  loop  system  configura¬ 
tion.  The  concept  focuses  attention  on  the  environmental 
"initiator,"  the  internal  process  function,  and  the  input  to 
and  output  from  the  internal  process  and  environment, 
including  enemy  forces,  own/neutral  forces  and  usual 
environmental  components.  [Ref.  7]  (This  concept  is 
explained  in  Chapter  III). 

(4)  Module  Four  (Integration  of  System  Elements 
and  Functions) 

Module  four,  the  integration  of  statics  and  dynamics  module, 
relates  the  information  flow  and  process  functions  to  the 
organizational  structure  as  well  as  relating  the  physical 
entities  ot  the  process  functions.  [Ref.  7] 

( 5 )  Module  Five  (Specification  of  Measures) 

[Module  five  is  the  specification  of  measures].  Guidelines 
are  provided  to  identify,  develop  and  select  measures  that 
gauge  the  C2  system’s  response.  These  measures  will  provide 
a  standard  for  comparison  as  the  underyling  architecture  of 
the  C2  system  is  reconfigured;  they  are  directly  tied  to 
operational  issues  relating  to  the  archtiecture.  [Ref.  8] 

( 6 )  Module  Six  (Data  Generation) 

Given  that  measures  have  been  selected,  the  sixth  module 
identifies  the  need  to  develop  a  data  generator  that  will 
provide  values  for  the  C2  system's  response.  [Ref.  8] 

Module  six  encompasses  data  generation  by  exercise, 
simulation,  experiment,  and/or  subjective  judgements. 

[Ref.  7] 


( 7 )  Module  Seven  (Aggregation  of  Measures) 

In  the  seventh  module,  techniques  are  provided  to  aggregate 
measures  in  a  way  that  relates  measurement  of  C2  response  to 
combat  outcome.  [Ref. 8] 

The  decision  maker  has  several  options  after 


progressing  through  the  seven  modules.  The  options  are  do 
nothing,  implement  results,  or  make  another  iteration  through 
one  or  more  of  the  seven  MCES  modules.  [Ref.  9] 


The  author  will  integrate  the  conceptual  model 
of  MCES  with  the  MEO  concept  in  order  to  provide  some  insight 
into  how  to  address  interoperability  problems  on  an  architec¬ 
tural  level. 
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III.  EXPANSION  OF  MCES  FOR  INTEROPERABILITY  ANALYSIS 


A.  INTRODUCTION 

This  chapter  serves  to  demonstrate  the  application  of  MCES 
as  a  tool  to  assist  C2  managers  and  planners  to  better  define 
interoperability  requirements  of  C2  communications  architectures 
through  improving  their  ability  to  manage  the  sort  of  inter¬ 
operability  problems  addressed  in  Chapter  II,  Section  B  titled 
"HISTORICAL  PRECEDENCE  FOR  THE  WORK." 

In  this  MCES  application,  Pipho's  concept  of  a  MEO  will  be 
added  as  the  major  tool  for  interoperability  analysis.  The  MEO 
is  considered  to  be  the  basic  building  block  for  C2 
communications  architectures  and  the  fundamental  unit  of 
interoperability.  This  concept  will  be  further  expanded  by  the 
author  . 

B.  BACKGROUND 

The  author  first  attempted  to  apply  Pipho's  concept  of  a 
MEO  as  described  in  Pipho's  paper  titled  "Cutting  the  Gordian 
Knot  of  Interoperability:  A  Sy stems-Engineered  Solution  to  the 
Problem  of  Interoperability  Modeling"  [Ref.  2]  to  an  air 
defense  C2  architecture.  The  author  used  the  Marine  Corps' 
"Technical  Interface  Concepts  for  Marine  Tactical  Systems," 
otherwise  known  as  the  "TIC"  to  verify  Pipho's  claim. 
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[The  TIC]  .  .  .  establishes  Marine  Corps  interoperability  and 
intraoperability1  requirements.  In  these  areas,  it  provides 
planning  guidance  for  true  specification  and  development  of 
Marine  Corps  tactical  data  systems,  equipments,  and  procedures. 
[Ref.  10;  p.  1] 

The  following  is  quoted  from  the  TIC  concerning 

information  exchange  requirements: 

Information  exchange  requirements  were  developed  from 
approved  doctrine,  existing  standing  operating  procedures, 
and  established  techniques  played  against  a  scenario 
depicting  Marine  Corps  units  in  .  .  .  amphibious  and  land 
combat  operations.  These  requirements  were  further 
categorized  and  correlated  with  the  broad  operational  tasks 
and  information  categories  of  JCS  Pub  12,  providing  two-way 
traceability  between  defined  agency  [OPFAC]  tasks  and  the 
broad  operational  tasks.”  [Ref.  10:  pp.  1-2] 

From  the  above  quote,  the  TIC  should  be  able  to  support 

Pipho's  MEO  approach  to  designing  a  C2  architecture.  But  the 

author  found  that  it  does  not  as  described  below. 

The  author  defined  the  archecture  C2Es^  as  shown  in  Figure 

3.1  for  an  air  defense  scenario.  The  air-defense  system  was 

defined  by  the  following  control  facilities/agencies: 

-  Tactical  Air  Control  Center  (TACC) 

-  Tactical  Air  Operations  Center  (TAOC) 

-  Light  Antiaircraft  Missile  Battery  (LAAM) 

-  Forward  Area  Air  Defense  Battery  (FAAD) 

-  Combat  Air  Patrol  (CAP) 


1 

Intraoperability  is  equivalent  to  interoperability  except 
that  intraoperability  is  concerned  with  operations  within  one 
system,  whereas  interoperability  is  focused  on  operations 
between  different  systems. 


2 

The  TIC  refers  to  the  C2E  concept  as  an  operational 
facility  (OPFAC)  [Ref.  14:  p.  2-1]  The  terms  C2E  and  OPFAC 
will  be  used  interchangeably  in  this  chapter. 


He  then  proceeded  to  identify  the  information  exchange 


requirements  between  C2Es  without  much  success.  Although  the 


basic  ideas  supporting  the  MEO  concept  are  there,  the  descrip¬ 


tion  of  the  tasking  of  OPFACs  is  not  appropriate.  There  is  no 


definitive  way  to  implement  the  resultant  exchange  information 


exchange  requirements.  The  author  found  it  impossible  to  iden¬ 


tify  what  type  of  information  had  to  be  exchanged  between  C2Es 


using  the  TIC.  Therefore,  the  author  was  unable  to  build  MEOs 


and  consequently  he  was  also  unable  to  design  an  air  defense 


architecture  from  the  TIC  alone. 


The  OPFAC  tasks  were  not  logically  organized.  An  OPFAC  task 


consists  of  a  five  digit  number.  The  first  three  digits 


represents  a  particular  OPFAC,  i.e.,  OPFAC  #650  (TACC)  (See 


Appendix  A).  The  last  two  digits  identify  a  functional  area 


category  (See  Appendix  B).  Numbers  were  assigned  to  OPFAC 


tasks  without  regard  to  operational  considerations;  such  as  the 


force  level  (company,  battalion,  or  division)  or  the  interrela¬ 


tionships  of  tasks. 


The  narrative  summaries  in  the  TIC  associated  with  the 


OPFAC  tasks  do  not  allow  distinguishing  between  hierarchical 


levels,  e.g.,  MAU  vs  MAF,  or  between  specific  mission  areas. 


such  as  anti-air  warfare  and  land  combat  operations.  This 


made  it  impossible  to  apply  Pipho's  MEO  approach  to  analyze 


interoperability  requirements,  at  the  appropriate  level  and  for 


designated  missions  from  the  TIC.  Therefore,  an  additional 


technique  as  described  in  the  next  section  was  developed 


mwsvsi 


C.  DESCRIPTION  OF  PROBLEM 

Recalling  that  a  MEO  is  defined  by  a  source  C2E,  sink  C2E, 
a  message  standard,  and  a  link  standard,  the  author  expanded 
the  TIC's  approach  to  interoperability  management  requirements. 
In  order  to  define  a  MEO,  its  four  elements  must  be  identified 
in  terms  of  their  characteristics.  First  both  source  and  sink 
C2Es  are  determined.  These  are  very  easy  to  characterize, 
while  the  remaining  two  elements  of  a  MOE  are  not.  The  message 
standards  are  dependent  on  what  type  of  tasks  are  being  per¬ 
formed.  However,  all  too  frequently,  the  tasks  to  be  performed 
are  neither  well  delineated  nor  well  documented.  Since  tasks 
are  often  difficult  to  define,  message  standards,  which  depend 
on  task  definitions,  are  subsequently  difficult  to  charac¬ 
terize.  Link  standards,  in  turn,  are  dependent  on  message 
standard  characteristics.  The  relationship  between  C2Es  and 
tasks  can  be  analogous  to  a  sentence  structure  diagram  CSee 
Figure  3.2).  The  C2Es  can  be  considered  to  be  similar  to 
sub ject/ob ject  which  are  the  "doers";  while  the  task  can  be 
equated  to  a  verb,  which  describe  the  action  between  the  C  2  F.  s . 
[Ref.  11] 

A  C2E  can  be  characterized  by  its  (1)  nation,  (2)  service, 
(3)  branch,  (4)  echelon,  and  (5)  unit.  The  following  is  an 
example;  Communications  Support  Company,  Eight  Communications 
Battalion,  Force  Service  Support  Group,  Fleet  Marine  Force 
Atlantic,  United  States  of  America.  If  the  unit  is  unique  and 
one  is  familar  with  it,  one  mav  also  know  the  identify  of  its 


Unit 


Figure  3.2.  C  E  and  Task  Structure. 
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echelon,  branch,  service,  and  nation;  such  as  in  the  example: 
Communication  Support  Company  is  unique  to  the  U.S.  Marine 
Corps  and  the  Eight  Communications  Battalion,  so  the  other 
organizational  levels  are  implicitly  known.  A  unit  has  certain 
resources  (equipment  and  personnel)  which  further  characterizes 
a  C2E.  [Ref.  11] 

Task  or  OPFAC  task  are  not  as  easily  characterized.  The 
TIC  is  a  first  attempt  at  task  specification;  however,  as 
indicated  previously,  its  approach  is  not  refined  enough  to  meet 
this  challenge.  The  narrative  summaries  defining  OPFAC  tasks 
are  too  broad.  They  address  several  tasks  which  makes  it  very 
difficult  to  identify  what  is  actually  being  done  and  what 
information  requirements  are  associated  with  a  given  task. 

Also,  if  one  could  identify  the  information  requirements  needed 
to  develop  message  standards  for  a  collection  of  MEOs,  they 
most  likely  could  not  work  backwards.  That  is,  given  an  MEO, 
what  task  is  associated  with  it?  The  narrative  summary  for 
OPFAC  task  65001  (TACC)  is  provided  to  illustrate  the  above 
point.  [Ref.  11] 

TACC  Task  67500.  Supervise  and  coordinate  the  operational 
planning  and  tactical  execution  thereof  by  subordinate  and 
supporting  agencies  to  preserve  economy  and  unity  of  effort, 
while  ensuring  the  accomplishment  of  the  missions  of  the  TACC 
in  support  of  the  MAGTF  objectives;  modify  the  tasking  of 
supporting  agencies  as  required.  [Ref.  10:  p.  D-2] 

Examining  the  above  narrative,  it  is  very  difficult  to  tell 

where  one  task  ends  and  another  begins.  Also,  it  is  impossible 


to  determine  what  organizational  level  this  summary  is 


referring  to.  However,  assuming  there  is  an  MEO  defined  for  one 
of  the  tasks  contained  in  the  above  summary,  it  would  be  very 
difficult,  if  not  impossible,  to  tell  what  task  the  MEO  is 
related  to. 

Using  the  MCES  structure,  the  author  synthesized  the  above 
approaches  to  characterizing  C2Es  to  respond  to  the  analytic 
challenge  of  characterizing  tasks. 

1 .  Problem  Formulation 

There  are  two  foci  in  this  thesis,  (1)  operational 
considerations  and  (2)  methodological  issue. 

a.  Operational  Considerations 

After  their  attempt  to  design  an  air  defense  C2 
architecture  using  the  TIC,  both  the  author  and  Pipho  agreed 
that  the  methodology  set  forth  in  the  TIC  should  be  examined 
and  analyzed  for  its  ability  to  adequately  address 
interoperability  problems  on  an  architectural  level.  This  was 
undertaken  by  employing,  as  a  test  case,  the  OPFAC  tasks 
associated  with  a  C2  communications  architecture  that  is 
required  to  produce  an  air  tasking  order  (Frag). 

b.  Methodological  Issue 

Conversely,  by  examining  the  procedures  associated 
with  the  air  tasking  order,  this  thesis  will  verify  the  ability 
of  a  Lawson-like  C2  Process  model  to  practically  describe 


service  doctrine. 


The  physical  entities  of  the  C2  communications 
architecture  are  the  Combat  Operations  Center  Marine  Air-Ground 
Task  Force  (COC  MAGTF),  Combat  Operations  Center  Ground  Element 
(COC  GE),  and  Tactical  Air  Command  Center  (TACC).  (See  Figure 
3.3)  These  three  OPFACs  are  the  C2Es  of  a  Marine  Amphibious 
Brigade  (MAB).  The  COC  GE  and  TACC  are  considered  to  be  on  the 
same  organizational  level,  although  the  TACC  supports  the  COC 
GE  with  air  support  requirements.  Each  of  the  C2Es  are 
commanded  by  a  commander  who  is  supported  by  a  staff.  The 
commander  of  the  COC  MAGTF  is  called  the  MAGTF  commander  or  MAB 
commander,  but  for  this  thesis  the  MAGTF  commander  title  will 
be  used.  The  COC  GE  is  commanded  by  the  Ground  Combat  Element 
Commander  (GCE)  who  is  responsible  for  identifying,  planning, 
and  establishing  target  priorities  and  coordinating  the  air 
attacks  as  directed  by  the  MAGTF  commander  [Ref.  12:  p.  1-4]. 
The  ACE  commander  has  the  authority  to  plan,  control,  and 
coordinate  all  air  operations  within  his  assigned  area  [Ref. 

12:  p.  1-4],  Both  the  GCE  commander  and  ACE  commander  report 
directly  to  the  MAGTF  commander  who  is  in  charge  of  the  overall 
combat  operation. 

The  bounding  process  also  specifies  the  physical 
relationship  of  C2Es.  Although  this  C2  communications 
architecture  is  organized  to  employ  the  doctrine  of  centralized 
control,  the  physical  entities  are  by  doctrine  distributed 
physically.  (See  Figure  3.4)  In  one  typical  scenario,  the 


Figure  3.3.  Organizational  Structure  for  a  MAGTF . 


TACC  is  located  ten  miles  north  and  five  miles  west  of  the  COC 


MAGTF,  while  the  COC  GE  is  located  five  miles  north  and 
fifteen  miles  east  of  the  COC  MAGTF.  This  geographic 
separation  is  a  consideration  when  defining  interoperability 
requirements  of  communications  systems.  Essential 
interoperability  requirements  are  depicted  in  Figure  3.5a, 
while  intraoperability  requirements  within  an  OPFAC  are 
illustrated  in  Figure  3.5b. 

3 .  C2  Process  Definition 

a.  Marine  Air-Ground  Task  Force 

The  Marine  Air-Ground  Task  Force  (MAGTF)  is  a  force  of 
combined  arms  task  organized  for  a  specified  mission.  The 
MAGTF  may  be  employed  in  an  amphibious  operation  or  a  land 
campaign.  In  either  concept  of  employment  the  MAGTF  is  task 
organized  to  exploit  the  combat  power  inherent  in  closely 
integrated  air  and  ground  forces.  [Ref.  12:  p.  1-1] 

For  the  purposes  of  this  thesis,  the  author  only  considered  the 
ACE  commander  plus  his  immediate  staff  working  in  the  TACC  as 
the  air  component,  as  well  as  the  GCE  commander  plus  his  imme¬ 
diate  staff,  manning  the  COC  GE,  as  the  ground  component  force. 
So,  the  MAGTF  for  this  problem  consisted  of  the  TACC  and  COC  GE 
under  the  direction  of  the  MAGTF  commander. 

( 1 )  Ground  Combat  Element  Commander  (GCE) 

[The  GCE  commander  is  responsible  to  the  MAGTF  commander]. 
Through  target  analysis  and  his  assigned  mission  objectives, 
the  GCE  commander  recommends  the  apportionment  and  alloca¬ 
tion  of  offensive  air  support.  The  GCE  commander  decides 
by  priority  which  targets  require  interdiction  by  aviation. 
While  selecting  targets  for  air  interdiction,  the  GCE 
commander  receives  and  estimate  of  aviation  support 
required  to  atack  these  targets  and,  by  subtraction,  deter¬ 
mines  how  many  remaining  air  assets  will  be  available  for 
close  air  support.  Once  the  air  interdiction  targets  are 


48 


Figure  3.5a.  Essential  Interoperability  Requirements 
for  Air  Tasking  Order. 
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.5b.  Intraoperability  Requirements  Within  an 
OPFAC . 


identified,  the  MAGTF  commander  approves  the  offensive  air 
support  apportionment  and  allocation.  The  GCE  commander  must 
now  decide  how  much  of  the  remaining  air  assets  to  use  for 
preplanned  CAS  [close  air  support]  missions,  and  how  much,  if 
any,  to  place  in  an  appropriate  alert  condition  for  immediate 
CAS  missions.  [Ref.  12:  p.  1-4] 

(2) 

The  ACE  commander  commands  a  supporting  force  the  "air 
arm."  Within  the  division  of  authority,  the  ACE  commander  is 
responsible  to  the  MAGTF  commander  for  analyzing  all  aspects 
of  antiair  warfare,  formulating  an  antiair  warfare  concept  to 
include  offensive  and  defensive  requirements,  and  presenting 
the  concept  for  approval.  The  ACE  commander  also  provides 
the  ground  combat  element  commander  (GCE)  with  an  estimate  of 
the  aviation  capability  that  can  be  applied  to  the  remaining 
function  offensive  air  support.  [Ref.  12:  p.  1-4] 

The  aviation  combat  element  of  the  larger  MAGTF's  normally 
possesses  diverse  employment  capabilities.  However, 
considering  the  threat  that  the  MAGTF  will  likely  face, 
planning  for  the  effective  employment  of  its  tactical  air  arm 
is  not  a  simple  matter.  The  MAGTF  relies  heavily  on  its 
aviation  force,  and  every  effort  must  be  made  to  insure  its 
most  effective  employment.  In  "target  rich"  environments, 
tactical  air  resources  will  rarely  be  sufficient  to  meet 
demand.  [Ref.  12:  p.  1-1] 

Therefore,  it  is  paramount  that  the  air  tasking  process  be  well 

defined  in  terms  of  functional  requirements. 

( 3 )  Aviation  Tactical  Functions 

The  aviation  combat  element  is  task  organized  to  provide  the 
required  functional  air  requirements  of  the  MAGTF.  The 
functions  of  principal  concern  to  the  air  tasking  process  are, 
(1)  antiaiar  warfare,  (2)  offensive  air  support,  and  (3)  air 
command  and  control.  A  firm  knowledge  of  these  functions  and 
types  of  targets  associated  with  each  is  the  most  important 
requirement  for  understanding  the  air  tasking  process.  [Ref. 

12:  p.  1-1] 

Figure  3.6  graphically  depicts  the  air  tasking  process  as  done 


Aviation  Combat  Element  Commander 


in  the  Marine  Corps  according  to  the  Operational  Handbook  (OH) 
5-3,  Tasking  USMC  Fixed  Wing  Tactical  Aviation."  [Ref.  12: 
Appendix  A) ] 
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Figure  3.6.  MAGTF  Fixed  Wing  Air  Tasking  Process  (cont.) 
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b.  Mapping  C2  Functions 

One  of  the  MORS  working  groups  provided  a  basic 
model  that  represents  the  basic  arrangement  of  most  C2  processes 
This  conceptual  C2  model  is  shown  in  Figure  3.7.  This  model  is 
generally  characterized  by  six  C2  process  functions  which  have  a 
direct  or  indirect  influence  on  the  friendly  (own)  forces 
operating  in  the  environment.  [Ref.  3:  p.  5-3] 

( 1 )  Definitions  of  Functions 

The  six  C2  process  functions  as  defined  in  the 
text  titled  Command  and  Control  Evaluation  Workshop  [Ref.  3 : 
p.  5-5]  are  quoted  below: 

Sense — That  function  which  collects  data  necessary  to 
describe  and  forecast  the  environment,  which  includes: 

-  The  enemy  forces’  disposition  and  actions. 

-  The  friendly  forces'  disposition. 

-  Those  aspects  of  the  environment  that  are  common  to  both 
forces,  e.g.,  weather,  terrain,  and  neutrals. 

Assess--That  function  which  transforms  data  from  the 
function  into  information  about  intentions  and  capabilities 
for  enemy  forces  and  about  capabilities  of  friendly  forces 
for  the  purpose  of  determining  if  division  from  the  Desired 
States  warrants  further  action. 

Generate — That  function  which  develops  alternative  courses 
of  action  to  correct  deviations  from  the  Desired  State. 

Select--That  function  which  selects  a  preferred  alternative 
from  among  the  available  options.  It  includes  evaluation  of 
each  option  in  terms  of  criteria  necessary  to  achieve  the 
Desired  State. 

Plan--That  function  which  develops  implementaton  details 
necessary  to  execute  the  selected  course  of  action. 

Direct--That  function  which  distributes  decisions  to  the 
forces  charged  with  execution  of  the  decision. 
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A  single  OPFAC  performing  a  single  isolated 
task,  which  requires  no  interaction  or  feedback  considerations, 
can  be  modeled  by  Figure  3.7.  [Ref.  3:  p.  5-5]  This  C2 
process  is  summarized  below: 

.  .  .  there  are  interactions  with  the  environment.  These 

interactions  are  represented  by  a  stimulus  input  and  a 
response  output.  The  output  can  only  cause  and  action 
through  our  own  forces,  which  results  in  a  change  to  the 
overall  environment.  External  inputs  are  shown  coming  from 
the  environment  and  are  susceptible  to  both  natural  and 
human-initiated  environment  effects.  The  only  other  direct 
input  to  the  process,  the  desired  State,  establishes  an  error 
function  inside  the  loop.  This  error  function  causes 
processing  activity  to  continue,  or,  at  the  other  extreme, 
halts  processing  activity  when  the  Desired  State  is  believed 
to  be  reached.  [Ref.  3:  pp.  (5-3)  -  (5-5)] 

The  process  is  initiated  when  a  sensed  input  is  assessed 
and  is  determined  or  is  believed  to  be  in  error  with  a 
Desired  State  or  when  our  requirements  for  the  Desired  State 
change.  These  errors  cause  the  generation  and  selection  of 
options,  which  results  in  a  plan  intended  to  change  the 
environment.  The  object  is  to  minimize  the  difference 
between  the  assessed  and  desired  environment.  [Ref.  3:  p.  5-5] 

The  C2  process  involving  the  COC  MAGTF,  COC  GE,  and  TACC 

OPFACs  producing  an  air  tasking  order  is  much  more  complicated 

than  the  process  described  above.  This  point  will  be  addressed 

further  in  the  following  section. 

c.  Application  of  Air  Tasking  Order 

Relying  on  doctrinal  and  operational  experience, 

the  author  mapped  the  C2  functions  to  the  tasks  required 

to  produce  an  air  tasking  order.  The  flow  chart  in 

3 

The  air  tasking  order  tasks  were  obtained  from  the 
Operational  Handbook  (OH)  5-1,  Tasking  USMC  Fixed  Wing 
Tactical  Aviation.  Appendix  A. 


Figure  3.6  (the  shad  a  rectangles)  provides  a  graphical  mapping 
of  the  C2  process  functions  to  the  tasks,  while  in  Table  3.1  a 
tabular  mapping  is  presented.  Mapping  C2  functions  to  tasks 
was  not  straightforward.  As  can  be  seen  from  the  graphical 
mapping  of  C2  functions  to  tasks  in  Figure  3.6,  the  C2  functions 
do  not  follow  a  sequential  flow  as  depicted  in  Lawson-like 
conceptual  model  in  Figure  3.7. 

A  single  OPFAC  for  the  air  tasking  order  is  better 
represented  by  the  conceptual  model  designed  by  the  author  in 
Figure  3.8.  This  model  designed  by  the  author  is  the  same  as 
the  one  in  Figure  3.7,  except  that  it  includes  feedback  options 
for  each  function.  An  OPFAC  does  not  have  to  progress  sequen¬ 
tially  from  the  "sense"  function  through  to  the  "direct" 
function.  This  is  evident  as  seen  in  the  flow  chart  of  Figure 
3.6.  Theoretically  there  are  an  infinite  number  of  ways  that 
an  OPFAC  can  perform  the  functions  to  control  its  own  forces. 
This  model  is  fine  for  a  single  OPFAC  working  autonomously; 
however,  three  OPFACs  interacting  together  are  required  to 
produce  an  air  tasking  order.  Figure  3.8  is  inadequate  to 
model  the  coordination  among  three  independent  OPFACs. 

In  Figure  3.9  the  author  expanded  the  func¬ 
tional  feedback  option  concept  to  the  hierarchical-interactive 
relationship  of  the  COC  MAGTF,  COC  GE,  and  TACC.  The  princi¬ 
ples  of  operation  for  the  model  in  Figure  3.9  are  identical  to 
that  of  the  model  in  Figure  3.8,  with  two  additional  main 
points:  (1)  the  COC  MAGTF  establishes  the  Desired  State  for 


TABLE  3.1 


C2  PROCESS  FUNCTIONS  MAPPED  TO  AIR 
TASKING  ORDER  TASKS 


TASK 

NUMBER 

TASK 

DESCRIPTION 

C2  FUNCTIONS 

1 

1 . 1 

MAGTF  CDR  ISSUES 
APPORTIONMENT  GUIDANCE 

DIRECT 

1 

1.2 

MAGTF  CDR  ISSUES 
APPORTIONMENT  GUIDANCE 

DIRECT 

2 

1  .  1 

ACE  CDR  ISSUES 

PLANNING  GUIDANCE 

ASSESS 

2 

1.2 

ACE  CDR  ISSUES 

PLANNING  GUIDANCE 

DIRECT 

2 

2.1 

ACE/MAGTF  DEVELOP 

OFFENSIVE  AAW  TARGETS 

ASSESS 

2 

OJ 

. 

CM 

ACE/MAGTF  DEVELOP 

OFFENSIVE  AAW  TARGETS 

GENERATE 

3 

1  .  1 

ACE  DEVELOP  DEFENSIVE 

AAW  REQUIREMENTS 

ASSESS 

3 

1.2 

ACE  DEVELOP  DEFENSIVE 

AAW  REQUIREMENTS 

GENERATE 

3 

2.1 

ACE  INTEGRATES 

OFFENSIVE  AND  DEFENSIVE 

AAW  REQUIREMENTS  INTO 

AAW  CONCEPT 

SELECT 

3 

2.2 

ACE  INTEGRATES 

OFFENSIVE  AND  DEFENSIVE 

AAW  REQUIREMENTS  INTO 

AAW  CONCEPT 

PLAN 

TABLE  3.1 


C2  PROCESS  FUNCTIONS  MAPPED  TO  AIR 
TASKING  ORDER  TASKS  (CONTINUED) 


TASK 

NUMBER 

TASK 

DESCRIPTION 

C2  FUNCTIONS 

3 

3.1 

ACE  CALCULATES  SORTIES 
REQUIRED  FOR  AAW  AND 
AVAILABLE  FOR  OAS 

ASSESS 

3 

3.2 

ACE  CALCULATES  SORTIES 
REQUIRED  FOR  AAW  AND 
AVAILABLE  FOR  OAS 

GENERATE 

3 

3.3 

ACE  CALCULATES  SORTIES 
REQUIRED  FOR  AAW  AND 
AVAILABLE  FOR  OAS 

SELECT 

3 

3.4 

ACE  CALCULATES  SORTIES 
REQUIRED  FOR  AAW  AND 
AVAILABLE  FOR  OAS 

PLAN 

4 

1 . 1 

GCE  ISSUES  PLANNING 
GUIDANCE 

ASSESS 

4 

1.2 

GCE  ISSUES  PLANNING 
GUIDANCE 

DIRECT 

4 

2.1 

GCE  PREPARES  INITIAL 
ESTIMATES  OF  CLOSE 

AIR  SUPPORT  REQUIREMENTS 

ASSESS 

4 

2.2 

GCE  PREPARES  INITIAL 
ESTIMATES  OF  CLOSE 

AIR  SUPPORT  REQUIREMENTS 

GENERATE 

5  1.1 


GCE  DEVELOP  AND  PRIORITIES  SELECT 
AIR  INTERDICTION  TARGETS 


TABLE  3.1 


C2  PROCESS  FUNCTIONS  MAPPED  TO  AIR 
TASKING  ORDER  TASKS  (CONTINUED) 


TASK 

NUMBER 

TASK 

DESCRIPTION 

C2  FUNCTIONS 

5 

1.2 

GCE  DEVELOP  AND  PRIORITIES 
AIR  INTERDICTION  TARGETS 

PLAN 

6 

1 . 1 

MAGTF  CDR  CONVENES 
APPORTIONMENT  CONFERENCE 

DIRECT 

6 

1.2 

MAGTF  CDR  CONVENES 
APPORTIONMENT  CONFERENCE 

DIRECT 

7 

1 . 1 

ACE  BRIEFS  AAW  CONCEPT 

AND  ALTERNATIVES  EFFECTING 
OAS  CAPABILITY 

GENERATE 

7 

2.1 

DOES  THE  AAW  CONCEPT 

REQUIRE  MODIFICATION 

SELECT 

7 

2.2 

DOES  THE  AAW  CONCEPT 

REQUIRE  MODIFICATION 

ASSESS 

7 

3.1 

MAGTF  CDR  PROVIDES 

GUIDANCE  FOR  MODIFICATION 

OF  AAW  CONCEPT 

DIRECT 

7 

4.1 

ACE  MODIFIES  AAW  CONCEPT 

AND  COMPUTES  SORTIES 
AVAILABLE  FOR  OAS 

ASSESS 

7 

4.2 

ACE  MODIFIES  AAW  CONCEPT 

AND  COMPUTES  SORTIES 
AVAILABLE  FOR  OAS 

GENERATE 

60 


TABLE  3.1 


C2  PROCESS  FUNCTIONS  MAPPED  TO  AIR 
TASKING  ORDER  TASKS  (CONTINUED) 


TASK  TASK  C2  FUNCTIONS 

NUMBER  DESCRIPTION 


7  4 . 3  ACE  MODIFIES  AAW  CONCEPT  SELECT 

AND  COMPUTES  SORTIES 
AVAILABLE  FOR  OAS 

7  4.4  ACE  MODIFIES  AAW  CONCEPT  PLAN 

AND  COMPUTES  SORTIES 
AVAILABLE  FOR  OAS 


8  1.1  MAGTF  CDR  APPROVES  SELECT 

THE  AAW  PLAN 


9  1.1  MAGTF  CDR  APPROVES  THE  SELECT 

APPORTIONMENT  AND  ALLOCA¬ 
TION  OF  AAW  AND  OAS 


10  1.1  GCE  DETERMINES  AIR  INTER-  SELECT 

DICTION  TARGETS  TO  BE 
ATTACKED  WHILE  CONSIDER¬ 
ING  THEIR  COST  AND  THAT 
CAPABILITY  WHICH  REMAINS 
FOR  CAS 

1C  1.2  GCE  DETERMINES  AIR  INTER-  ASSESS 

DICTION  TARGETS  TO  BE 
ATTACKED  WHILE  CONSIDER¬ 
ING  THEIR  COST  AND  TH. 

CAPABILITY  WHICH  REMAINS 
FOR  CAS 


10  2.1  MAGTF  COMMANDER  APPROVES  SELECT 

AND/OR  MODIFIES  THE  AIR 
INTERDICTION 
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TABLE  3.1 


C2  PROCESS  FUNCTIONS  MAPPED  TO  AIR 
TASKING  ORDER  TASKS  (CONTINUED) 


TASK  TASK  C2  FUNCTIONS 

NUMBER  DESCRIPTION 


10  2.2  MAGTF  COMMANDER  APPROVES  GENERATE 

AND/OR  MODIFIES  THE  AIR 
INTERDICTION 


11  1.1  MAGTF  CMD  APPROVES  THE  PLAN 

APPORTIONMENT  AND  ALLOCA¬ 
TION  OF  AIR  INTERDICTION 
AND  CAS 

11  1.2  MAGTF  CMD  APPROVES  THE  DIRECT 

APPORTIONMENT  AND  ALLOCA¬ 
TION  OF  AIR  INTERDICTION 
AND  CAS 


12  1.1  GCE  SUBMITS  AIR  INTERDIC-  SELECT 

TION  TARGETS  BY  PRIORITY 
TO  ACE  FOR  TASKING 


13  1.1  DOES  THE  MAGTF  REQUIRE  ASSESS 

ADDITIONAL  AIR  SUPPORT 
ASSETS  FOR  AIR  INTERDIC¬ 
TION? 


13  2.1  ACE  IDENTIFIES  ADDITIONAL  GENERATE 

AIR  SUPPORT  REQUIREMENTS 
FOR  AIR  INTERDICTION 
TARGETS 

13  2.2  ACE  IDENTIFIES  ADDITIONAL  GENERATE 

AIR  SUPPORT  REQUIREMENTS 
FOR  AIR  INTERDICTION 
TARGETS 


TABLE  3.1 


C2  PROCESS  FUNCTIONS  MAPPED  TO  AIR 
TASKING  ORDER  TASKS  (CONTINUED) 


TASK  TASK  C2  FUNCTIONS 

NUMBER  DESCRIPTION 


13  3.1  GCE  CDR  DETERMINES  CAS 

ALLOTMENT  TO  INCLUDE  THE 
PREPLANNED  AND  IMMEDIATE 
MIX 

13  3.2  GCE  CDR  DETERMINES  CAS 

ALLOTMENT  TO  INCLUDE  THE 
PREPLANNED  AND  IMMEDIATE 
MIX 


14  1.1  GCE  UNITS  CONDUCT  DETAILED  PLAN 

FIRE  SUPPORT  AND  SEAD  PLAN¬ 
NING 


14  2.1  GCE  CDR  APPROVES  TAR'S  PLAN 

W/SEAD  REQUIREMENTS  AND 
SUBMITS  TO  ACE  FOR  TASKING 

14  2.2  GCE  CDR  APPROVES  TAR'S  DIRECT 

W/SEAD  REQUIREMENTS  AND 
SUBMITS  TO  ACE  FOR  TASKING 


15  1.1  ACE  DETERMINES  CAS  REQUIRE-  ASSESS 

MENTS 


15  2.1  ACE  INITIATES  PREPARATION  GENERATE 

OF  THE  AIR  TASKING  ORDER 


ASSESS 


SELECT 


TABLE  3.1 


C2  PROCESS  FUNCTIONS  MAPPED  TO  AIR 
TASKING  ORDER  TASKS  (CONTINUED) 


TASK 

NUMBER 

TASK 

DESCRIPTION 

C2  FUNCTIONS 

15 

3.1 

DO  OAS  REQUIREMENTS  EXCEED 
MAGTF  A/C  AVAILABLE? 

ASSESS 

15 

3.2 

DO  OAS  REQUIREMENTS  EXCEED 
MAGTF  A/C  AVAILABLE? 

ASSESS 

15 

4.1 

GCE  MODIFIES  IMMEDIATE- 
PREPLANNED  MIX  ASSISTED 

BY  ACE 

ASSESS 

1  15 

4.2 

GCE  MODIFIES  IMMEDIATE- 
PREPLANNED  MIX  ASSISTED 

BY  ACE 

ASSESS 

U  15 

4.3 

GCE  MODIFIES  IMMEDIATE- 
preplanne;  mix  assisted 

BY  ACE 

GENERATE 

15 

5.1 

GCE  MODIFIES  THE  AIR- 
INTERDICTIOM-CAS  MIX 
ASSISTED  BY  ACE/MAGTF 
(MAGTF  APPROVES) 

PLAN 

15 

5.2 

GCE  MODIFIES  THE  AIR- 
INTERDICT  ION-C  AS  MIX 
ASSISTED  BY  ACE/MAGTF 
(MAGTF  APPROVES) 

ASSESS 

15 

5.3 

GCE  MODIFIES  THE  AIR- 
INTERDICT  ION-C  AS  MIX 
ASSISTED  BY  ACE/MAGTF 
(MAGTF  APPROVES) 

GENERATE 

TABLE  3.1 


C2  PROCESS  FUNCTIONS  MAPPED  TO  AIR 
TASKING  ORDER  TASKS  (CONTINUED) 


TASK  TASK  C2  FUNCTIONS 

NUMBER  DESCRIPTION 


15  5.H  GCE  MODIFIES  THE  AIR  SELECT 

INTERDICTION -CAS  MIX 
ASSISTED  BY  AC E/MAGTF 
( MAGTF  APPROVES) 


15  6.1  ACE  MODIFIES  AAW  PLAN  PLAN 

(MAGTF  APPROVES) 

15  6.2  ACE  MODIFIES  AAW  PLAN  SELECT 

(MAGTF  APPROVES) 


15  7.1  IS  ADDITIONAL  AIR  ASSESS 

SUPPORT  REQUIRED  FOR 
AIR  INTERDICTION  OR 
CAS? 


15  8.1  ACE  IDENTIFIES  ASSESS 

ADDITIONAL  AIR 
SUPPORT  REQUIREMENTS 
FOR  CAS-AND/OR  AIR 
INTERDICTION 


15  9.1  ACE  FORWARDS  DIRECT 

ADDITIONAL  AIR  SUPPORT 
REQUIREMENTS  TO  MAGTF 
FOR  JTF  CONSIDERATION 


15  10.1  DOES  MAGTF  A/C  AVAIL-  ASSESS 

ABILITY  EXCEED  THE  AIR 
SUPPORT  REQUIREMENTS 


TABLE  3.1 


C2  PROCESS  FUNCTIONS  MAPPED  TO  AIR 
TASKING  ORDER  TASKS  (CONTINUED) 


TASK 

TASK 

C2  FUNCTIONS 

NUMBER 

DESCRIPTION 

15  11.1 

ACE  COMPUTES  EXCESS 
SORTIES  AND  FORWARDS 

TO  MAGTF  FOR  CROSS- 
TASKING  BY  JTF 

GENERATE 

15  12.1 

ACE  COORDINATES  AND 
INTEGRATES  ALL  AIR 
SUPPORT  REQUIREMENTS 

GENERATE 

15  12.2 

ACE  COORDINATES  AND 
INTEGRATES  ALL  AIR 
SUPPORT  REQUIREMENTS 

SELECT 

15  13.1 

ACE  DEVELOPS  AND 
COMPLETES  THE  AIR 
TASKING  ORDER  AND 
DISTRIBUTES 

PLAN 

15  13.2 

ACE  DEVELOPS  AND 
COMPLETES  THE  AIR 
TASKING  ORDER  AND 
DISTRIBUTES 

DIRECT 

15  13.3 

ACE  DEVELOPS  AND 
COMPLETES  THE  AIR 
TASKING  ORDER  AND 
DISTRIBUTES 

DIRECT 

COC  MAGTF 


^ENVIRONMENT 


Figure  3.9.  Expanded  C2  Process  Model  to  Show  Interaction 
Among  Three  Individual  OPFACs. 
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the  COC  GE  and  TACC  through  Directions.  Both  the  COC  GE  and 
TACC  have  the  option  to  coapare  any  point  ( C 2  function)  of  the 
C2  processing  to  the  Desired  State;  and  (2)  Each  of  the  three 
OPFACs  can  have  an  interaction  with  another  OPFAC  during  any 
point  in  the  C2  process. 

4 .  Integration  of  System  Eleaents  and  Functions 

"The  JINTACCS  prograa  has  derived  12  categories  of 
inforaation  exchange  requirements  among  and  between  various 
OPFACs.  When  an  individual  inforaation  categorv  is  applied  to 
each  of  the  12  operational  tasks,  the  content  of  the  category 
varies  according  to  the  task.  This  application  refines  *  h  e 
basic  12  inforaation  categories  in  defining  information 
exchange  requirements."  [Ref.  1  0 :  p.  1  -  *>  )  The  bounded  s  v  s  •  **  m 
'OPFACs  and  the  air  tasking  order  talks  ^  coupled  wi*h  *  k  *- 
information  category  codes  ']<'<>  <';ee  Append:*  <  pr -v.de  •  *  ► 

basis  for  the  integration  of  svstea  elements  and  fun**: 

Table  1.2  portrays  the  Integra'  ion  «<  f  *  h  e  '  P 1  A '  s  and  ’  i  ■■  *  s 
required  to  produce  an  air  tasking  >rde*.  T  n  *.  ’as.'  .  *  • 

2  are  reprodu<ed  f  rm  'he  Tasking  '  * ;  >  i  x  e  d  -  »  :  n  g  '  -a  -  '  -  a 

Aviation  ,  flp*rit  ioni!  H  a  n  d  b  »>  <>  k  .  T  *'  e  n  ,  u  s  -  n  g  •  *  e  •  -  -  ••••••• 

'able  for  '  1  functions  •  *  1  e  .  '  a  *  ’  *-  *  -  < 

*'  O  m  p  1  e  t  e  d  .  This  <r-‘Ss-ref*»ren-#»  »  a  '  e  sis  •  a 
experience.  !  n  f  o  r  m  a  ’  :  *  ■  *■  ‘T  t  ‘  ‘  e  ^  ; 

status  ni  f  r  i  end  1  v  s »  a  *  -i  «•  •*  « u  i  .  *  ♦  *•  *•  •  *  *  . 

sense  function.  Ana  1  *  /  :  "  it  *  *  -  •••*-▼>  a  ;  a  *  •  • 
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AND  FUNCTIONS  (CONTINUED) 
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INTEGRATION  OF  SYSTEM  ELEMENTS 
AND  FUNCTIONS  (CONTINUED) 


TABLE  3.3 


C 


2 


PROCESS  FUNCTIONS 
TO  INFORMATION 


CROSS-REFERENCED 

CATEGORIES 


C2  FUNCTION 


INFORMATION  CATEGORIES 


SENSE 

ENEMY  STATUS  (ES) 

FRIENDLY  STATUS  (FS) 

WEATHER  (WS) 

ASSESS 

ENEMY  CAPABILITIES  (EC) 
FRIENDLY  CAPABILITIES  (FC) 

GENERATE 

ALLOCATION /APPORTION ME  NT 
(AL) 

SELECT 

PRIORITIES  (PR) 

PLAN 

PLANS  (PL) 

DIRECT 

ORDERS  (OR) 

REQUEST  FOR  SUPPORT  (RS) 
REQUEST  FOR  INFORMATION  (RI) 

capabilities  is  the  sane  as  assessing  the  situation.  When  i 
commander  allocates,  he  is  refining  his  apportionment  de  ision. 
In  consideration  of  the  apportionment,  the  commander  prepares 
the  allocation  b  v  generating  specific  alternatives  and  making 
this  process  analogous  to  the  generate  function.  When  the 
commander  assigns  priorities  to  his  options  he  is  se..*cting 
among  his  alternatives,  which  is  similar  to  the  select 
function.  The  plans  category  is  straightforward  and  relates 
directly  to  plan  function.  Request  for  information,  request 
for  support  and  orders  are  results  of  a  commander  directing  a 
specific  response  from  a  subordinate  command;  they  are 
therefore  equivalent  to  the  direct  function. 

Having  cross-referenced  the  C2  functions  to  the  ICC 
in  Table  3.3,  the  author  relied  upon  doctrine  and  his  opera¬ 
tional  experience  to  select  the  appropriate  ICC  for  each  task. 
Columns  4  and  5  of  Figure  3.2,  the  transmitting  OPFAC  (XOPFAC) 
and  the  receiving  OPFAC  (ROPFAC),  were  chosen  by  the  tasks 
described.  If  the  tasks  statement  mentioned  the  "ACE,"  then 
the  TACC  (OPFAC  #650)  would  be  considered  as  the  source  and/or 
sink.  The  MAGTF  commander  would  correspond  to  the  COC  MAGTF 
(OPFAC  #600)  and  the  GCE  would  correspond  to  the  COC  GE  (OPFAC 
#601).  Again  the  author  had  to  rely  heavily  on  operational 
experience  when  determining  the  second  OPFAC.  The  second  OPFAC 
may  or  may  not  have  been  the  same  as  the  first.  When  both  the 
XOPFAC  and  ROPFAC  were  the  same,  this  implied  intraoperability 
as  opposed  to  interoperability.  The  final  column  titled  "OPFAC 
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task"  was  coaplated  by  comparing  the  first  five  columns  »  the 
0  P  F  A  C  tasks  narrative  suaaarien  contained  in  the  T I f ' ,  and 
selecting  the  " Boat"  appropriate  OPFAf  task(s).  Appendix  A 
provides  a  narrative  sumaary  from  each  of  the  OPFAf  tasks 
involved. 

The  last  three  MCES  modules  (Specification  of  Measures, 
Data  Generation,  and  Aggregation  of  Measures)  are  beyond  the 
scope  of  this  thesis.  However,  the  author  recommends  that 
remaining  modules  be  developed  further. 

D.  ANALYSIS  OF  THE  APPLICATION 

Recall  that  a  MEO  is  defined  by  a  unique  arrangement  of 
(1)  source  C2E,  (2)  Sink  C2E,  (3)  message  standard,  and  (4) 
link  standard.  The  better  the  characterization  of  the 
components  of  a  MEO,  the  easier  it  is  to  construct  MEOs.  The 
C2Es  are  easy  to  characterize  by  their  descriptive  elements 
(See  Figure  3.2),  but  message  standards  are  not.  The 
application  of  this  thesis  provides  some  insight  on  how  to 
refine  and  expand  the  characterization  of  tasks  which  determine 
message  standards. 

The  author  has  shown  that  the  tasks  associated  with 
producing  an  air  tasking  order  can  be  characterized  in  terms  of 
(1)  C2  functions,  (2)  information  category  codes,  (3)  C2Es,  and 
(4)  tasks  associated  with  a  C2E  (OPFAC  task)  (See  Table  3.2  and 
Figure  3.10).  These  characteristics  of  a  task  can  be  used  to 


Specifications  of  Measures,  Data  Generation 
and  Aggregation  of  Measures 


2 

Figure  3,10.  Structure  of  C  Es  and  their  Associated  Task 


identify  what  type  of  information  that  is  required  to  be 
exchanged  between  two  OPFAC.  C 2  planners  can  use  information 
requirements  to  define  standardized  message  exchanges  between 
two  OPFACs,  which  define  message  standards.  Once  message 
standards  are  defined,  C2  planners  can  decide  what  kind  and  how 
many  data  elements  are  required  to  adequately  identify  the 
information  needed  in  the  message  standard.  The  number  of 
data  elements  and  the  speed  of  which  they  must  be  exchanged 
between  OPFACs  would  be  used  to  define  the  link  standard.  The 
author  has  identified  a  more  precise  way  to  define  the 
components  of  a  MEO,  which  should  be  used  to  construct  MEOs. 

Once  all  potential  MEOs  and  their  descriptive  charac¬ 
teristics  have  been  identified,  coded  and  recorded  in  an 
integrated  interoperability  database  (IIDB),  C2  planners 
could  use  this  vast  amount  of  information  to  manage 
interoperability  problems.  For  instance,  a  planner  may  want  to 
know  what  communications  equipment  is  required  to  support  an 
air  defense  mission.  He  could  enter  the  IIDB  and  ask  for  all 
MEOs  associated  with  an  air  defense  mission.  Then  he  could 
request  the  communications  equipment  which  could  support  the 
particular  link  standards  associated  with  those  MEOs.  Or  he 
may  desire  to  know  what  tasks  are  performed  within  an  air 
defense  mission.  If  so,  he  would  ask  for  the  message  stan^rds 
of  the  MEOs  associated  with  air  defense.  Then  he  would  ask  for 
the  tasks  relating  to  the  message  standard.  Also,  the  C2 
planner  could  manage  interoperability  requirements  by  using  the 


IIDB  and  asking  a  question  such  as:  given  units  ”A,"  "B,"  "r," 
and  "D,"  what  types  of  communications  equipment  is  required  to 
support  them  in  a  particular  exercise  and  does  all  the  equip¬ 
ment  exist?  And  if  not,  given  the  available  resources  what 
MEOs  are  involved  and  what  tasks  can  be  supported?  One  can 
begin  to  see  that  almost  any  question  about  interoperability' 
intraoperability  can  be  addressed  and  answered  using  an  IIDB. 
[Ref.  11] 
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CONCLUSIONS  AND  RF.C  1 M  M  E  N  D  A 


IV  . 


i 


I 

( 


A.  OPERATIONAL  CONSIDERATIONS 

1 .  Weaknesses 

The  concept  of  defining  interoperability  an4 
intraoperability  requirements  of  >'2  architecture*  :  n 
MOEs  is  not  a  trivial  matter.  The  artual  method  s\  *  h  i  ■  *■  •  '•  «- 
Marine  Corps  and  other  services  operate  must  ho  accurate.* 
verified  and  documented.  Doctrinal  publications  are  required 
to  distinctly  reflect  the  actual  ways  in  which  the  services  muv 
operate.  This  effort  will  call  for  the  services  to  think  and 
plan  in  a  broader  perspective.  They  will  have  to  reorganise 
their  thinking  in  order  to  implement  and  adhere  to  a  "truly" 
systematic  approach  when  addressing  operational  considerations. 

2 .  Strengths 

The  overall  concept  of  distinctly  defining  the  tasks 
which  are  involved  in  operational  missions  is  a  sound  idea. 

This  concept  will  enable  military  commanders  to  train  their 
force  in  a  more  realistic  way.  The  services  will  have  a  better 
grasp  on  what  things  they  can  do  and  can  not  do.  They  will 
have  a  methodology  that  will  permit  them  to  view  the  tasks 
necessary  to  support  an  operation,  along  with  the  resources 
required.  This  methodology  gives  the  commander  a  tool  to 
effectively  and  efficiently  manage  his  assets. 
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icvf r« !  different  levels  tan  he  addressed.  Be  1 nv  are  three 


inter  operabilitv  standards  referenced  in  the  "Marine  Corps 


Inter  operabilitr  Management  Plan"  IRef.  11:  p.  2  - 1 n  ] 


(a)  Operational  Interoperability  Standards  that  specify 
military  objectives / operational  requirements,  tactical 
doc t r i ne / pr oc edu r es ,  standard  military  language,  and 
specific  information  exchange  plan. 


(b)  Procedural  Interoperability  Standards  that  specify 
procedures  related  to  the  forms  in  which  information  is 
transferred,  standards  reporting  language,  and  operating 
procedures  for  data  .  .  .  links. 


(c)  Technical  Interoperability  Standards  that  specify 
functional,  electrical,  and  physical  characteristics 
necessary  to  allow  the  exchange  of  information  between 
different  equipment  systems. 


Characterizing  interoperability  standards  is  simple  in  concept, 


but  far  reaching  in  terms  of  future  applications. 


4.  Future  Directions 


C2  planners  can  use  the  tools  contained  in  the  MEO 


concept,  this  thesis,  TIC,  and  MCES  to  identify  the  necessary 
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information  for  an  IIDB.  In  his  paper  titled,  "CUTTING  THE 

GORDIAN  KNOT  OF  INTEROPERABILITY:  .  .  Pipho  states: 

The  Marine  Corps  is  currently  in  the  early  stages  of 
developing  a  C2  interoperability  database  that  embodies  the 
MEO  concept.  Figure  [4.1]  is  a  diagram  of  the  data  model  for 
this  database  as  it  now  stands.  The  heavy  lines  indicate 
where  the  basic  components  of  the  MEO  are  found.  Implementa¬ 
tion  of  this  database  is  scheduled  to  occur  over  the  next  two 
years.  Completion  of  this  project  will  validate  and  provide 
the  Marine  Corps  with  an  effective  tool  to  achieve  inter¬ 
operability  among  its  C2  systems.  [Ref.  2] 

Also,  needed  will  be  a  way  to  tie  measures  to  the 
IIDB.  MCES  would  be  an  excellent  methodology  to  apply 
developing  these  measures  and  in  analyzing  interoperability 
requirements . 

C2  planners  could  ask  such  questions  as:  (1)  "given 
several  implementation  of  a  potential  C2  communications 
architecture,  which  one  is  significantly  better  or  worse  than 
the  others?"  Or  (2)  "given  a  particular  collection  of  resources 
(personnel  and  equipment),  what  type  of  missions  can  be  perform? 
and  how  well  can  they  be  executed?" 

B.  METHODOLOGICAL  ISSUES 
1 .  Weaknesses 

As  stated  previously,  the  basic  idea  of  the  I !  -  -  , 

But  trying  to  implement  the  concepts  contained  in  the  ' 
difficult  at  best.  Some  of  the  OPFAC  tasks  contari'  1 
TIC  are  ill  defined  and  in  many  cases  it  is  d  :  t  ‘  ■ 
date  the  "most"  appropriate  OPFAO  task  t  •  ■  i  ^  • 

were  many  cases  where  several  OF  Mi  ..  . 
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to  capture  the  essence  of  the  task  being  performed,  although 
only  portions  of  each  OPFAC  task  actually  related  to  the  given 
task.  Figure  4.2  illustrates  this  point.  In  this  figure  one 
can  graphically  see  that,  if  each  of  the  four  OPFAC  tasks’ 
narrative  descriptions  were  reduced  to  the  size  of  the  accented 
areas,  the  OPFAC  tasks  would  be  better  defined.  And  as  a 
result,  C2  planners  would  not  have  to  wade  through  unnecessary 
information.  Simply  eliminating  text  from  an  OPFACs  narrative 
summary  would  not  necessarily  result  in  a  better  defined  OPFAC 
task.  Omitting  text  would  more  likely  change  the  connotation 
of  the  narrative  summary,  rather  than  creating  a  better  defined 
OPFAC  task.  In  essence,  the  functional  area  category  codes  which 
are  the  fourth  and  fifth  digits  of  an  OPFAC  tasks  number  should 
be  defined  so  that  they  relate  to  only  one  task.  Then  C2 
planners  would  not  have  to  wade  through  unnecessary  information 
to  identify  the  relationship  between  tasks  and  OPFAC  tasks. 

2 .  Strengths 

The  overall  concept  of  this  thesis,  of  distinctly 
characterizing  OPFAC  tasks,  is  "usable."  Air  tasking  is 
performed  by  all  services  and  the  author  has  used  an  available 
set  of  tools  by  combining  MCES  and  the  MEO  methodology  to 
demonstrate  this  point.  By  combining  these  tools  the 
author  has  provided  an  approach  supported  by  a  substantial 
database  to  address  the  issue  of  interoperability  management. 


This  was  not  previously  possible. 


Figure  4.2.  Mapping  OPFAC  Tasks  to  a  Given  Task* 
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3 .  New  Insights  Gained 

Given  that  C2Es  and  message  standards  are  both 
contained  in  a  MEO,  and  that  C2Es  can  be  characterized  by  the 
organizations  that  are  associated  with  them,  message  standards 
should  be  characterized  by  the  tasks  associated  with  them. 

Along  the  same  reasoning,  if  C2Es  are  on  different  organiza¬ 
tional  levels,  they  should  be  classified  hierarchically.  If 
tasks  (functional  area  categories)  are  structured  hierarchi¬ 
cally,  they  create  a  perfect  vehicle  to  architecturally 
translate  a  given  task  into  organizational  units.  But  if  tasks 
(functional  area  categories)  are  not  structured  hierarchically, 
then  it  is  implied  that  a  given  task  should  be  treated  the  same 
regardless  of  what  level  in  an  organization  it  pertains  to. 
[Ref.  11] 

An  additional  insight  gained  from  this  thesis  is 
captured  by  the  illustration  in  Figure  4.3.  Intuitively,  the 
author  suggests  that  the  six  C2  process  functions  not  only  have 
a  nonsequential  execution  through  feedback  loops  (as  depicted 
in  Figure  3.8  and  Figure  3.9)  but  the  six  C2  functions  are  not 
mutually  exclusive.  Essentially  all  six  C2  function  are 
involved  throughout  any  C2  process.  However,  not  all  C2 
functions  may  be  involved  with  the  same  degree  of  intensity, 
and  therefore  they  may  be  disregarded. 

4 .  Future  Directions 

It  is  clearly  evident  that  there  is  still  much  work  to 
be  done  in  order  to  have  a  useful  IIDB.  The  author  recommends 


.  .  2 
Figure  4.3.  Intersection  of  C  Process  Functions. 
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the  five  efforts  listed  below  be  undertaken,  as  soon  as 
possible : 

(a)  Refine  the  functional  area  categories  in  the  TIC,  so 
that  they  more  closely  relate  to  the  actual  tasks  per¬ 
formed  for  a  given  mission  area.  This  includes  organizing 
and  coding  the  functional  area  categories  on  a  hierarchical 
structure . 

(b)  Identify  information  requirements  for  each  newly  defined 
OPFAC  task,  based  on  the  information  category  codes. 

(c)  Construct  MEOs  for  all  mission  areas. 

(d)  Once  MEOs  have  been  defined,  store  them,  along  with  their 
components  which  characterize  them,  into  an  IIDB. 

(e)  Run  queries  on  the  IIDB  and  use  MCES  as  a  tool  to  analyze 
the  MEO  concept  to  improve  interoperability  management. 

MCES  can  be  expanded  to  address  questions  on  an  architectural 

level,  such  as:  given  architecture  A  and  architecture  B  which 

system  can  best  support  a  specific  combat  mission?  Once  the 

IIDB  is  operational,  it  will  speed  up  the  analysis  of  the  types 

of  problems  stated  in  the  previous  section  (IV. A. 4)  titled 

"OPERATIONAL  CONSIDERATIONS,  Future  Directions." 

This  thesis  points  out  to  the  C2  community  an  existing 
approach  that  the  Marine  Corps  is  embarking  upon.  The  C2 
community  has  not  used  and  does  not  use  this  approach,  but 
should  be  aware  of  it  because  they  can  model  their  own 
service's  unique  tools  after  it. 
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APPENDIX  A 


OPERATIONAL  FACILITIES  (OPFAC)  TASKS 
The  functional  tasks  are  presented  in  the  following 
paragraphs  under  the  appropriate  OPFAC.  These  OPFAC  tasks  were 
extracted  from  the  TIC  [Ref.  10:  pp.  D-3  -  D-17].  The  tasks  are 
listed  in  generally  the  same  order  as  OPFACs  are  presented  in 
the  TIC. 

Combat  Operations  Center  -  Marine-Air-Ground  Task  Force  Tasks 

.  COC  MAGTF(M)  Task  60000.  Receive  initiating 

directive  from  higher  authority;  receive  planning 
information  from  all  mission  planning  agencies;  develop 
mission  plans  and  operation  orders  for  the  conduct  of 
operations  by  subordinate  and  supporting  units  of  the 
Marine  Air/Ground  Task  Force  (MAGTF).  Submit  plans/ 
orders  to  supporting  agencies  for  coordination  and 
guidance,  and  to  subordinate  agencies/units  for  execution. 

.  COC  MAGTF(M)  Task  60001.  Supervise  and  coordinate  the 
operational  planning  and  tactical  execution  thereof  by 
subordinate  and  supporting  agencies  to  preserve  economy 
and  unity  of  effort,  while  ensuring  the  accomplishment  of 
objectives  of  the  MAGTF;  modify  the  tasking  of  supporting 
agencies  as  required. 

.  COC  MAGTF(M)  60011.  Ensure,  during  the  planning  and 

execution  stages,  the  integration  of  all  air,  artillery, 
mortar,  and  naval  gunfire  in  support  of  the  scheme  of 
maneuver  of  the  ground  forces. 

.  COC  MAGTF(M)  Task  60012.  Allocate  assets  to  subordinate 
and  supporting  agencies  for  the  operation  when  approved 
plans  have  been  promulgated.  Request  allocation  of  support 
from  higher  headquarters  when  support  requirements  cannot 
be  met  from  organic  assets. 

.  COC  MAGTF(M)  Task  60015.  Maintain  the  status  of  the 

capabilities  of  friendly  and  enemy  forces.  Receive  opera¬ 
tional  reports  and  intelligence  data  from  supporting 
agencies;  consolidate  and  forward  to  cognizant  head¬ 
quarters,  keeping  them  advised  of  progress  toward  meeting 
objectives . 
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COC  MAGTF(M)  Task  60065.  Receive/initiate  and  disse¬ 
minate  tactical  alerts  and  warnings  concerning  enemy 
activity  and  delivery  of  chemical  or  nuclear  munitions  by 
friendly  forces,  to  ensure  the  safety  and  tactical 
integrity  of  force  units. 

COC  MAGTF(M)  Task  60070.  Establish  the  EMC0N/EW  policy 
for  the  MAGTF . 

COC  MAGTF(M)  Task  60075.  Receive,  evaluate,  and 
disseminate  combat  information  to  support  MAGTF 
operations,  utilizing  reconnaissance  and  surveillance 
reports,  and  other  reports  from  units  in  contact  with 
the  enemy. 

Combat  Operations  Center  Ground  Element  Tasks 

COC  GE(M)  Task  60100.  Receive  initiating  directive 
from  higher  authority;  receive  planning  information  from 
all  mission  planning  agencies;  develop  mission  plans  and 
operation  orders  for  the  conduct  of  operations  by  sub¬ 
ordinate  and  supporting  units  of  the  ground  element  (GE). 

Submit  plans/orders  to  senior  headquarters  for  approval, 
to  supporting  agencies  for  coordination  and  guidance,  and 
to  subordinate  agencies/units  for  execution. 

COC  GE(M)  Task  60101.  Supervise  and  coordinate  the 
operational  planning  and  tactical  execution  thereof  by 
subordinate  and  supporting  agencies  to  preserve  economy 
and  unity  of  effort,  while  ensuring  the  accomplishment 
of  the  objectives  of  the  GE;  modify  the  tasking  of  the 
supporting  agencies  as  required. 

COC  GE(M)  Task  60111.  Ensure,  during  the  planning 
and  execution  stages,  the  integration  of  all  air, 
artillery,  mortar,  and  naval  gunfire  in  support  of  the 
scheme  of  maneuver  of  the  ground  forces. 

COC  GE(M)  Task  60112.  Allocate  assets  to  subordinate 
and  supporting  agencies  for  the  operation  when  approved 
plans  have  been  promulgated.  Request  allocation  for 
support  from  higher  headquarters  when  support  requirements 
cannot  be  met  from  organic  assets. 

COC  GE(M)  Task  60115.  Maintain  the  status  and  capa¬ 
bilities  of  friendly  and  enemy  forces.  Receive  opera¬ 
tional  reports  and  intelligence  data  from  supporting 
agencies;  consolidate  and  forward  to  cognizant 
headquarters,  keeping  them  advised  of  progress  toward 
meeting  objectives. 
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COC  GE(M)  Task  60165.  ''eceive/initiate  and  disseminate 
tactical  alerts  and  warnings  of  enemy  activity,  and 
delivery  of  chemical  or  nuclear  munitions  by  friendly 
forces,  to  ensure  the  safety  and  tactical  integrity  of 
force  units. 

Tactical  Air  Command  Center  Ta^ks 

TACC(M)  Task  65001.  Supervise  and  coordinate  the 
operational  planning  and  tactical  execution  thereof  by 
subordinate  and  supporting  agencies  to  preserve  economy 
and  unity  of  effort,  while  ensuring  the  accomplishment 
of  the  missions  of  the  TACC  in  support  of  the  MAGTF 
objectives;  modify  the  tasking  of  supporting  agencies  as 
required . 

TACC(M)  Task  65015.  Maintain  complete  information  on 
the  air  situation,  including  that  ground  combat  information 
essential  to  the  air  effort.  Keep  cognizant  agencies 
advised . 

TACC(M)  Task  65041.  Manage  all  aircraft  in  the  A0A  to 
ensure  the  most  balanced  and  properly  weighted  utilization 
of  assets  for  tactical  air  operations. 

TACC(M)  Task  65043.  Develop  detailed  FRAG  orders  to 
support  the  operations  of  the  assault  forces.  Advise 
supporting  arms  agencies  of  the  air  support  schedule  in 
order  to  integrate  air  support  with  artillery  and  naval 
gunfire  support.  Disseminate  the  FRAG  orders  to  air  units 
and  control  agencies  for  execution. 

TACC(M)  Task  65052.  Divert  aircraft  from  scheduled 
missions  to  meet  other  priority  requirements;  notify 
affected  agencies  and  brief  pilots  as  required. 

TACC(M)  Task  65055.  Establish  and  promulgate  procedures 
for  employment  of  air  defense  weapons  in  overlapping  sector 
of  responsibility. 

TACC(M)  Task  65061.  Coordinate  search  and  rescue 
operations  for  the  MAGTF. 

TACC(M)  Task  65065.  Provide  appropriate  air  defense 
alert  conditions  to  all  major  elements  of  the  MAGTF. 

TACC(M)  Task  65068.  Establish  alert  conditions  for 
ground  alert  aircraft. 


•  TACC(M)  Task  65070.  Prescribe  electronic  emission 
control  (EMCON)  conditions  and  electronic  warfare  (EW) 
procedures  for  MACCS  agencies  in  the  objective  area. 

•  TACC(M)  Task  65072.  Coordinate  the  gathering  of 
sensor  information!  including  radar  contacts  and 
electronic  emissions,  and  report  the  information  to 
command  elements  and  air  control  agencies. 
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FUNCTIONAL  AREA  CATEGORIES 

The  functional  area  categories  listed  below  are  quoted 
directly  from  the  TIC.  (Ref.  10:  pp.  D-4  -  D-5] 


PLANS 

00 

Basic  Plans  and  OPORDs 

04 

Nuclear  and  Chemical  Fire 

01 

Sut  vise  and  Coordinate 

Plans 

Planning  and  Execution 

05 

Fire  Support  Plan  Assistance 

ol  Plans  and  Orders 

06 

Artillery  Fire  Plans 

02 

Support  mg  Arms  Plans 

07 

Counter  fire  plans 

0J 

Naval  Cunt  ire  Plans 

08 

Air  Support  Plans 

10 

Inforinat i< >n  Collection  Pi. ins 

ASSETS 

11 

Integration  ol  Assets 

12 

Allocation  ot  Assets 

SITUATION 

15 

Friendly  ana  Kneny  Status 

18 

Status  Displays/Dissemination 

OK  STATUS 

16 

Supporting  Arms  Situation 

19 

Status  of  Landings 

17 

Aircraft  Status  and 

20 

Unit  Location  and  Status 

Capabilities 

21 

Friendly  Aircraft  Location 

FIRE 

25 

Provide  Supporting  Arms 

30 

Receive  Calls  for  Fire 

SUPPORT 

Support 

31 

Call  for  and  Adjust  Fires 

26 

Monitor  Fires/Safety 

32 

Control  NGF  and  Artillery 

27 

Limiting  Measures 

Fire 

28 

Coordinate  NGF , 

33 

Registration  Fires 

Artillery,  Mortar  Support 

34 

Fire  Direction 

29 

Requests  for  NGF, 

35 

Fire  Commands/Satety 

Artillery,  tvortar  Support 

36 

Target  Information 

AIR 

40 

Command  Subordinate 

46 

Provide  Air  Support 

SUPPORT 

Agencies 

47 

Direct  Air  Strikes 

41 

Manage  Aircraft 

48 

Control  Aircraft 

42 

Coordinate  with  External 

49 

Assign  A/C  to  Control  Agencie. 

Agencies 

50 

Requests  for  Air  Support 

43 

Schedules/ FRAG  Orders 

51 

Air  Support  Requirements 

44 

Coordinate  Friendly  Aircraft 

52 

Adjust/Divert 

45 

Coordinate/ Act  for  Control 

53 

Coordinate  DAS  Execution 

Agencies 

54 

Coordinate  FAAD  Teams 

55 

Coordinate  Air  Defense 

58 

Movement  Into  and  Out  of 

56 

Identify  and  Track  Aircraft 

Landing  Zone 

57 

Landing  Zone  Operations 

59 

Provide  Air  Defense 
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FUNCTIONAL  AREA  CATEGORIES  (CONT#D) 


FLIGHT 

60 

Flight  Advisories 

63 

GCA/ Radar  /  I*i .  i  gj*: ;  on 

Assistant* 

ASS  IS- 

61 

SAR  Operations 

64 

Air  Track  Luta 

TANCE 

62 

Radar  Handover 

WARNINGS 

65 

Receive/Disseminate 

67 

Ordnance  Release 

AND 

66 

Nuclear  and  Chemical 

68 

Strip  Alert  Lota 

ALERTS 

Delivery 

SENSOR 

70 

EMCON/EW  Policy 

72 

Coordinate  Sensor  Data 

71 

Coor  d  i  na  t  e/Hon  i  t  o  r 

73 

Provide  Sensor  Data 

EMCON/EW 

INTELk- 

74 

Collect  Information 

76 

Reconnaissance  and 

gence/ 

75 

Process  Intelligence  Data 

Surveillance 

OPERA- 

TIONAL 

77 

Results 

ROUTES 

80 

Approach  and  Retirement 

AND 

POINTS 

81 

Alteration 

BRIEFINGS 

85 

Brief  Aircrews 

87 

Brief  Agencies  on  Status 

86 

Brief  Observers 

CONFLICTS 

90 

Supporting  Arms  Conflicts 

92 

Priorities 

91 

Safety  Conflicts 

METBOPO- 

95 

Meteorological  Data 

LOGICAL 

AND 

SURVEY 

96 

Survey  Data 

i 

i 

f 
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INFORMATION  CATEGORIES 

The  information  contained  in  this  appendix  is  quoted  from 
the  TIC  [Ref.  10:  pp.  3-5  -  3-7]. 

Information  Categories.  The  JINTACCS  program  has  derived  12 
categories  of  information  from  JCS  Pub  12  to  identify  the  infor¬ 
mation  exchange  requirements  among  and  between  various  OPFACs. 
When  an  individual  information  category  is  applied  to  each  of 
the  12  operational  tasks,  the  content  of  the  category  varies 
according  to  the  task.  This  application  provides  for  a  refine¬ 
ment  of  the  basic  12  information  categories  in  defining 
information  exchange  requirements. 

a.  Allocation/ApportionmentCAL).  An  allocation  is 
refinement  of  the  apportionment  decision  made  by  the  force 
commander.  An  example  is  the  apportionment  decision  made  by  the 
division  of  the  total  tactical  air  capabilities  among  air  strike 
tasks  to  be  performed  for  a  specific  period.  In  consideration 
of  the  apportionment,  the  commander  prepares  the  allocation  by 
designating  specific  numbers  and  types  of  aircraft  sorties  for 
use  during  the  specified  time  period.  Necessary  allocation 
information  is  transmitted  from  the  commander(s)  to  the  compo¬ 
nents  included  in  the  apportionment  and  to  the  joint  task  force 
headquarters . 

b.  Enemy  Capabilities  (EC).  This  category  provides 
intelligence  on  possible  future  courses  of  action  by  the  enemy 
which  may  affect  the  accomplishment  of  the  assigned  joint  task 
force  mission.  The  term  "capability"  includes  not  only  the 
general  courses  of  action  open  to  the  enemy,  such  as  attack, 
defense,  or  withdrawal,  but  also  all  specific  courses  of  action 
possible  under  each  general  course  of  action.  Enemy  capabili¬ 
ties  are  considered  in  light  of  all  known  factors  affecting 
military  operations,  including  time,  space,  weather,  terrain, 
and  the  strength  and  disposition  of  enemy  forces.  It  does  not 
involve  the  current  situation  of  the  enemy,  but  deals  with 
possible  future  actions  of  the  enemy.  As  used  in  this  docu¬ 
ment,  information  in  this  categoryo  is  generated  by  an  opera¬ 
tional  facility  as  a  result  of  analyzing  and  evaluating 
information  obtained  from  its  own  resources  and/or  of 
information  obtained  from  other  operational  facilities, 
including  a  reassessment  of  enemy  capabilities  generated  by 
other  operational  facilities. 

c.  Enemy  Status  (ES).  This  category  provides  information 
and/or  finished  intelligence  on  the  enemy  situation  as  it  cur¬ 
rently  exists.  It  may  include  historical  intelligence,  but  it 
excludes  possible  future  actions  by  the  enemy  from  all  sources, 
including  order  of  battle,  location  and  disposition,  movement 


speeds  and  direction,  target  and  installations,  scientific  and 
technical,  biographic,  nuclear,  biological,  and  chemical  and 
other  information  classified  as  current  or  combat  intelligence 
(e.g.,  contacts  and  sightings,  electronic  warfare,  imagery  and 
imagery  readouts,  prisoner-of-war  exploitation,  and  captured 
documents  and  material)  are  included  in  this  category,  except 
weather  (WX)  and  terrain  (TG). 

d .  Friendly  Capabilities  (FC).  This  category  provides  the 
commander's  evaluation  of  what  his  unit(s)  can  or  cannot  do  in 
the  future.  It  does  not  involve  the  present  situation  of  friend¬ 
ly  forces,  but  deals  only  with  possible  future  actions  and 
conditions  of  these  forces.  Information  in  this  category  includes 
potential  courses  of  action  by  friendly  units  which,  if  adopted, 
will  contribute  to  the  accomplishment  of  the  assigned  mission. 

It  also  includes  projected  status  and  availability  of  units,  or 
their  weapons  systems  or  other  material,  and  estimated  future 
strength  and  location  of  friendly  units.  It  does  not  include 
the  intention  of  the  commander,  but  may  describe  the  future 
friendly  situation  resulting  from  the  pursuit  of  those 
intentions . 

e.  Friendly  Status  (FS).  This  category  provides 
information  about  friendly  forces  as  they  currently  exist.  It 
includes  such  elements  as  strength,  composition,  location  and 
dispositon,  status  and  availability  of  resources,  movements  and 
activities,  movement  speeds  and  direction,  logistics,  signifi¬ 
cant  strengths  and  weaknesses,  nuclear,  biological,  and  chemical 
weapons,  and/or  technical  characteristics  of  equipment.  It 
describes  the  friendly  situation  as  it  currently  exists,  not  as 
it  may  exist  in  the  future. 

f .  Orders  (OR).  This  category  involves  directives  to 
take  action.  It  does  not  include  information  concerning  what 
the  commander  intends  to  do  in  the  future,  but  may  tell  the 
recipient  what  the  commander  requires  to  be  done  in  the  future. 

For  weapons  systems,  it  may  include  instructions  such  as  fire, 
cease  fire,  track,  drop  track,  vector,  attack,  etc.  It  also 
includes  such  directives  as  operations  orders,  warning  orders, 
fragmentary  orders,  etc. 

g.  Plans  (PL).  This  category  consists  of  a  method  or 
scheme  for  a  future  military  action.  It  represents  the 
commander's  translation  of  his  decisions  and  concepts  of 
operation  into  preparing  for  action  in  a  specific  area  to  meet 
a  particular  event,  and  it  conveys  the  commander's  intentions 
for  accomplishing  this  event.  K  plan  will  not  become  an  order 
without  appropriate  implementing  instructions. 

h .  Priorities  (PR).  This  category  involves  the 
commander1!! ranking  the  elements  of  any  situation  in  the  order 
of  each  element's  importance  to  the  accomplishment  of  the 
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mission.  Priority  information  may  involve  establishing  the 
precedence  of  elements  relative  to  time,  space,  or  any  number 
of  other  limiting  factors.  The  ranking  indicates  relative 
importance;  it  is  not  an  exclusive  and  final  designation  of  the 
order  of  accomplishment.  For  example,  the  DASC  assigns  a 
priority  to  each  request  for  close  air  support  submitted  by 
ground  agencies;  the  TACC  assigns  priorities  for  air  defense 
protection  to  specific  areas,  facilities,  units,  or  activities 
within  the  area  of  operations. 

i.  Request  for  Information  (RI).  This  category  tells  the 
recipient  that  information  is  needed  for  use  in  decision  making. 
This  category  does  not  include  requests  for  support  (RS).  It  is 
not  used  to  obtain  information  which  is  otherwise  required  to  be 
transmitted  as  a  result  of  orders  or  of  execution  of  plans,  but 
is  used  to  obtain  information  for  amplification  or  clarifica¬ 
tion,  or  information  that  is  otherwise  excepted  from  reporting. 
Such  requests  may  be  general  or  specific  in  nature,  and  may  or 
may  not  require  recurrent  responses.  It  may  be  used  to  obtain 
information  on  enemy  or  friendly  status  or  capabilities,  weather 
or  terrain.  It  may  also  be  used  to  request  further  orders  from 
a  superior,  or  to  interrogate  other  commanders  about  their  plans 
or  priorities. 

j.  Request  for  Support  (RS).  This  category  is  part  of  the 
process  of  allocating  and  reallocating  combat  resources.  The 
support  requested  encompasses  any  action  on  the  part  of  an 
agency  which  aids,  protects,  complements,  or  sustains  another 
agency  when  engaged  in  tactical  operations. 

k .  Ter r a in/Geogr aphic/Oce an o graphic /Hydrographic 

Information  (TG).  This  category  of  information 
pertains  to  all  aspects  of  the  environment,  natural  or  manmade, 
other  than  weather.  It  includes  the  configuration,  composition, 
fauna,  flora,  cultural  features,  and  hyudrological  and  geophysi¬ 
cal  characteristics  of  the  land  and  all  aspects  of  the  sea.  It 
includes  navigational  information,  fallout,  effects  of  chemical 
weapons,  induced  radiation  data,  and  such  mand-made  obstacles  as 
minefields,  barbed  wire,  concertinas,  and  underwater  barriers. 

l .  Weather  (WX).  This  category  of  information  pertains 
to  all  past,  current,  and  forecasted  meteorological,  climatolo¬ 
gical,  and  sea  conditions. 
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